Хочу поделиться с сообществом простым и полезным шаблоном скрипта-обёртки на bash для запуска заданий по cron (а сейчас и systemd timers), который моя команда повсеместно использует много лет.

Сначала пара слов о том зачем это нужно, какие проблемы решает. С самого начала моей работы системным администратором linux, я обнаружил, что cron не очень удобный планировщик задач. При этом практически безальтернативный. Чем больше становился мой парк серверов и виртуальных машин, тем больше я получал абсолютно бесполезных почтовых сообщений "From: Cron Daemon". Задание завершилось с ошибкой - cron напишет об этом. Задание выполнено успешно, но напечатало что-нибудь в STDOUT/STDERR - cron всё равно напишет об этом. При этом даже нельзя отформатировать тему почтового сообщения для удобной автосортировки. Сначала были годы борьбы с использованием разных вариаций из > /dev/null, 2> /dev/null, > /dev/null 2>&1, | mail -E -s '<Subject>' root@.

Сборная солянка из существующих best practices по работе с Grafana и немного с Prometheus, проверенных мной лично. Можно просто положить в закладки — когда-нибудь да пригодится.

Речь пойдет о сборке, настройке и запуске охранной системы с датчиками, камерой, хранением видеозаписей на удаленном домашнем NAS, встроенным UPS, web-интерфейсом и оповещением через Telegram.

Чтобы быть предельно кратким, оформил статью в стилистике hackster.io. Информация рассчитана на читателей с опытом работы с одноплатным компьютером Raspberry и пониманием принципов работы VPN.

Сами по себе логи, трейсы, метрики - это очень узкие артефакты состояния нашего объекта наблюдения и обслуживания. Для понимания общей картины нужен взгляд сверху, сбор всех важных сигналов в одну систему и работа с большими данными в ней. Зонтичный подход близок по своим целям к RED и Golden Signals, но по своей сути является противоположным по принципу работы с данными. В Golden Signals мы отслеживаем Latency, Traffic, Errors отдельных сервисов и по ним можем быстро, но очень поверхностно определить их состояние. В случае зонтичного мониторинга или AIOps мы собираем данные о всех логах, событиях систем мониторинга метрик и трейсов, далее выстраиваем там топологию сервиса и определяем алгоритмически состояние здоровья, основываясь на сотнях и тысячах событий, метрик и трейсов. И два подхода, кстати, друг друга не исключают. В этой статье я постараюсь сравнить четыре бесплатных инструмента, которые могли бы дать такую зонтичную картину: ELK, Graylog, Grafana Loki и Monq.

Год назад мы выпустили «Маскировщик» — промышленный софт, который обезличивает персональные данные, сохраняя их качество и смысл. То есть гендерный баланс; социально‑демографическую структуру; родственные связи; страну и оператора в телефоне; валидность паспортов, ИНН, СНИЛС. В общем, «Маскировщик» делает так, чтобы вы тестировали продукты и обучали ML‑модели будто бы на «живых» ПД.

В этой статье пролью свет на методы изменения состава и семантики, которые использует продукт. Для простоты буду называть их «алгоритмами маскирования». Расскажу, по какой логике меняем одни данные другими, какие ограничения и как учитываем.

В 1997 году американский криптограф и специалист по компьютерной безопасности Брюс Шнайер написал первый в мире менеджер паролей — Password Safe. Это была простая и бесплатная утилита для Windows 95 с примитивным пользовательским интерфейсом и базой данных в виде зашифрованного файла, внутри которого хранился список логинов и паролей.

Однако последние 20 с лишним лет менеджеры эволюционировали. Сегодня это полноценные кроссплатформенные приложения с продвинутым интерфейсом и множеством полезных (и не очень) фич. В этой статье мы рассмотрим, какие менеджеры паролей бывают и в каких ситуациях они будут полезны.

В этой статье ищем и находим решение задачи по организации удаленного доступа к Ubuntu: минусы VNC и RDP, история альтернативного протокола — NX, преимущества и работа с X2Go

Этот пост я хочу посвятить кейсу с крупного ИТ-проекта, который делала наша компания. В рамках проекта внедрялось большое количество сервисов, и для них нужно было обеспечить LDAP-аутентификацию при следующих операциях:

• Доступ в GUI-интерфейсы сервисов.

• Доступ по SSH на серверы, где функционируют сервисы, с ограничением доступа на основании членства пользователей в группах LDAP-каталога.

У заказчика уже была развернута служба каталогов Microsoft Active Directory. Требованием проекта было отсутствие прямого доступа между внедряемыми сервисами и AD. На стороне сервисов не должны были прописываться параметры сервисных учетных записей AD. Кроме того, сетевой доступ к контроллеру MS AD был разрешен только для одного хоста.

Под катом — подробности о том, как мы решили эту задачу.

Надоело, что одни пороги метрик настроены в Prometheus, другие в Zabbix, третьи еще в каком‑то Zabbix? А когда трясет инфру и vCenter, то с vROps летят оповещения, причем те же самые о виртуалках, что поставлены на мониторинг в первом и втором Zabbix?!

Тут можно менять названия уровней вашего ИТ‑окружения, можно менять названия систем мониторинга. Дубли, штормы, алярмы и алармы. Проблема будет знакома всем, кто работает с большими инфраструктурами. А еще не забываем о проблеме «сложить все в одну банку»: все метрики с разных прометеев, например; ну и, конечно же, совсем было бы здорово в одной системе увидеть все метрики и логи и настроить по ним корреляции и автоматизацию.

А так можно было? Конечно!

Идея этой статьи с сантехническим уклоном у меня возникла после просмотра в Ютубе видеоролика о монтаже нового секционного биметаллического радиатора при замене старого отопительного прибора типа «гармошка» в старой однотрубной системе отопления, которую с советских времён применяют в подавляющем количестве панельных домов.

В этом видосике сошлись в смертельной схватке два «блогера‑сантехника», каждый из которых считал, что только он прав.

По результатом этой баталии у меня возникли альтернативные решения, не совпадающие полностью ни с одним из дуэлянтов.

Своё видение решения я описал в комментариях к видеоролику, но ответа не получил. В итоге решил написать эту статью для прояснения сути проблемы широкой массе жителей панельных домов.

Особый интерес к этой теме у меня возник потому, что я сам лично как‑то собрался поменять такую старую облезлую «гармошку» (см.рис.1) на новый белый и красивы биметаллический радиатор (см.рис.2).

Сколько помню домашние роутеры, всегда была возможность установить на них какую-нибудь неофициальную прошивку, и роутер начинал работать стабильнее (не всегда). Потом появилась возможность добавлять пакеты, расширяющие функциональность роутера.

Сейчас, благодаря бурному развитию ARM архитектуры, мы можем приобрести довольно мощные, компактные железки за адекватную стоимость. А производители начали расширять функциональность прошивок. Если, например, вам нужна только поддержка USB модема, то многие роутеры могут предоставить это из коробки.

А если фукционала из коробки не хватает и хочется большего, то нужно как раньше смотреть в сторону неофициальных прошивок.

В последние 8 лет мой фаворит - это OpenWrt, прошивка на базе ядра Linux. Это полноценная операционка, в которой есть свой менеджер пакетов и туда до сих пор не проник systemd.

Всем привет! Меня зовут Валентина Ляликова. Я ведущий бизнес-аналитик в X5 Tech и преподаватель направления «Пользовательские истории и критерии приёмки» в Школе бизнес-анализа X5 Tech. 

Большой опыт работы на разнообразных проектах помог сформировать мне список правил, которых я придерживаюсь каждый день при написании User Story и Acceptance Criteria (US+AC). В этой статье хочу поделиться ими с вами и показать на примерах ошибочных вариантов написания документа US+AC, почему так важно применять эти правила в работе.

Приступая к работе в ЦОД, можно легко запутаться в различных типах кабелей, которые используются для соединения и подключения сетевых устройств и серверов. Некоторые из них распространены и в повседневной жизни, а потому хорошо узнаваемы – Ethernet-кабели (с коннекторами RJ-45) и кабели питания (например, с распространенными вилками C13). Но другие, такие как оптические кабели с коннекторами стандарта SFP, LC, SC, силовые с вилкой типа IEC-309 и т. д., известны не так широко.

Если вы проводите какие-либо работы непосредственно в стойке, любая ошибка может стоить дорого – нажата не та кнопка, и клиенты уже в дауне, а любимые и глубоко уважаемые специалисты техподдержки шлют вам тикеты счастья. Даже Uptime Institute в своем исследовании 2021 года отмечает, что в 79% случаев причиной падения серверов в ЦОДах является человеческий фактор.  Всё надо делать вовремя – и нажимать кнопки, и менять комплектующие, и переключать кабели… 

Так вот о кабелях. Чтобы начать с ними работать, было бы неплохо хотя бы знать, как они выглядят и какие функции выполняют. 

Этот материал как раз об этом. 

В первую очередь, он будет полезен в роли шпаргалки сотрудникам-стажерам, только начинающим работу с аппаратной частью ИТ-инфраструктуры. 

Привет! В статье поделюсь, как инструмент автоматического рефакторинга Rector помогает обуздать легаси и автоматизировать обновление PHP проектов и пакетов, чтобы процесс проходил эффективнее и малой кровью. 

Статья написана на основе доклада с PHP Russia 2022.

Привет, я Виктор. Двенадцать лет назад я пришел в веб-студию в Самаре. Так начался мой путь в разработке. У нас не было гита, CI/CD, тестовых стендов и много чего еще. Я видел, как это мешало развитию команды и бизнеса. Приходилось на ощупь собирать грабли, открывать для себя хорошие практики и внедрять их. С тех пор я поработал старшим разработчиком в российском финансовом холдинге и немецком b2b-стартапе. Был тимлидом в фудтех-проекте, СTO в образовательных стартапах для российского и латиноамериканского рынка — и почти везде поначалу натыкался на похожие проблемы. Недавно переехал в Израиль, стал консультировать стартап. И что бы вы думали…

Рассмотрим на примере вымышленной ситуации

Михаил Михайлец, руководитель группы аналитиков направления облачных решений Лиги Цифровой Экономики, порассуждал о роли аналитика в команде и для этого смоделировал ряд ситуаций, когда к работе над проектом стоит привлекать таких специалистов. О том, что из этого получилось — читайте в статье.

— Аналитики не нужны! — лицо Лаврентия, нового менеджера проекта по внедрению информационной системы по управлению всем (ИС СУВ) не выражало никаких эмоций, а степень решимости была сродни количеству лошадиных сил у грузового локомотива. За плечами Лаврентия — опыт разработки в IT-гиганте из Fortune 500, с коллегами он изобретал свой особенный форк gRPC и участвовал в эксперименте по переходу на трехчасовые спринты.

— Это же пустая трата времени. Лиды встретились, договорились по параметрам API, реализовали и в прод, — продолжил он и сдвинул брови.

— А документация... — начал было тимлид аналитики Савелий. За его плечами — десятки часов чтения ГОСТ и семь аналитиков.

— Скормим ChatGPT, потом студенты на аутсорсе поправят, — парировал Лаврентий.

— А веб-интерфейс?

Над Савелием будто сгустились тучи.

— Останемся на прежнем, а если что, — кнопки покрасить не проблема, — отрезал менеджер проекта и кивнул на fullstack Прасковью.

— Да, — отозвалась Прасковья, его вторая жена.

— А…

— Все, за работу! — отчеканил Лаврентий в ответ на пробившиеся было сквозь поток негодования Савелия аргументы и вышел.

В переговорке воцарилось тяжкое молчание. Казалось, тишину нарушает лишь шум разогнавшихся синапсов в головах членов команды.

В этой статье мы говорим о грамотном размещении оборудования в стойке, а иными словами, системно рассматриваем эксплуатацию серверного шкафа: от составления плана и инсталляции до маркировки проводов. Всё повествование строится, в первую очередь, на моем опыте работы инженером ЦОД, и, хорошо это или не очень, я стараюсь придерживаться именно этих правил и практик.