• Какие бывают требования и чем они характеризуются,
• Типы задач и порядок их описания в Issue tracker,
• Как оформлять User story и Tech story,
• Как описывать баги,
• Настройка конвейера развертывания.

• когда повторять запрос (retries);
• как выбрать значения для таймаутов;
• как не убить нижележащие серверы в момент аварии/перегрузки;
• нужны ли health checks;
• как обрабатывать «мерцающие» проблемы.

Сетевой стек Linux по умолчанию замечательно работает на десктопах. На серверах с нагрузкой чуть выше средней уже приходится разбираться как всё нужно правильно настраивать. На моей текущей работе этим приходится заниматься едва ли не в промышленных масштабах, так что без автоматизации никуда – объяснять каждому коллеге что и как устроено долго, а заставлять людей читать ≈300 страниц английского текста, перемешанного с кодом на C… Можно и нужно, но результаты будут не через час и не через день. Поэтому я попробовал накидать набор утилит для тюнинга сетевого стека и руководство по их использованию, не уходящее в специфические детали определённых задач, которое при этом остаётся достаточно компактным для того, чтобы его можно было прочитать меньше чем за час и вынести из него хоть какую-то пользу.

Текстовых редакторов также, как и средств разработки стало довольно много и трудно выбрать из них необходимый. Предлагаю ознакомиться с лучшими представителями данного класса программ из числа тех, что доступны для Linux ОС и имеют открытый исходный код.

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

Не знаю, на каком языке программирования вы пишете, но уверен, что используете Гит при разработке. Инструментов для сопровождения разработки становится всё больше, но даже самый маленький тестовый проект, я неизменно начинаю с команды git init. А в течение рабочего дня набираю в среднем ещё 80 команд, обращаясь к этой системе контроля версий.

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

На Хабр написано много статей о Гите, но они не уходят дальше официальной документации, а упрощать работу авторы предлагают самописными костылями. Я уверен, что изучать Гит нужно на конкретных примерах задач, а повышать эффективность работы с ним – стандартизированными средствами.

Кому будет полезна эта статья?

Вы уже освоили джентльменский набор Гита и готовы двигаться дальше? Существует 2 пути:

1. Освоить сокращённые команды – алиасы. Они почти всегда составлены мнемонически и легко запоминаются. Забыть оригиналы команд проблематично, я легко их набираю, когда это требуется. Плюс не сбиваюсь с мысли, проверяя что-то в Гите в процессе написания кода.
2. Узнать о дополнительных флагах к командам, а также их объединении между собой. Я понимаю, что кто-то ненавидит сокращения. Для вас тоже есть интересный материал в статье – как повысить полезность и удобство вывода команд, а также как решать не самые тривиальные, но часто встречающиеся на практике задачи.

Посвятите описанным в статье экспериментам пару часов сегодня, и сэкономьте по приблизительным расчётам полгода рабочей жизни.

Добро пожаловать под кат!

1. работоспособность в условиях моргания сети (первое правило распределенных систем — никому не говорить о распределенных системах сеть ненадежна)
2. отсутствие единой точки отказа

• пространство ключей образует дерево (иерархию подобную файловой системе)
• значения могут содержаться в любом узле иерархии, а не только в листьях (как если бы файлы одновременно были бы и каталогами), узел иерархии называется znode
• между клиентом и сервером двунаправленная связь, следовательно, клиент может подписываться как изменение конкретного значения или части иерархии
• возможно создать временную пару ключ/значение, которая существует, пока клиент её создавший подключен к кластеру
• все данные должны помещаться в память
• устойчивость к смерти некритического кол-ва узлов кластера

В предыдущей статье мы поделились своим опытом внедрения и использования СУБД ClickHouse в компании СМИ2. В текущей статье мы затронем вопросы масштабирования, которые возникают с увеличением объема анализируемых данных и ростом нагрузки, когда данные уже не могут храниться и обрабатываться в рамках одного физического сервера. Также мы расскажем о разработанном нами инструменте для миграции DDL-запросов в ClickHouse-кластер.

• сбор всех данных за раз, полученных в JSON от консольной утилиты счетчика электроэнергии Меркурий 236
• сбор показателей S.M.A.R.T. жестких дисков и SSD, полученных в табличном виде от smartmontools.

Привет! Все мы знаем и любим такие продукты для vulnerability assessment процессов как Nessus, Qualys, Max Patrol и всякие прочие OpenVAS. Одной из основных задач, которые они решают, является обеспечение контроля версионных уязвимостей.

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

Существует масса разнообразных инструментов для решения этой задачи, но у всех них с нашей точки зрения есть одна общая проблема — они требуют отдельного хлопотного развертывания и порождают в вашей инфраструктуре еще один инструмент с root-овой учетной записью. Но ведь для такого простого действия как сбор информации об установленных пакетах root не нужен! Да и обычно в инфраструктуре уже присутствуют развернутые системы с возможностью консолидации данных, совместной работы и удаленного исполнения команд на серверах. Поэтому мы решили сделать инструмент, который позволил бы в пару кликов развернуть в своей среде систему контроля уязвимостей Linux с минимальными изменениями продакшена.

Что развернуто в большинстве продуктовых систем? Конечно же мониторинг. И довольно часто это Zabbix. Так давайте к нему и прикрутимся!