Архив рубрики ‘DevOps’

Между нами SLA: как бизнесу и поддержке договориться до первого инцидента

Разбор SLA от человека, которого подключают, когда сайт недоступен, заказы не проходят, а в чатах уже ищут виноватых. Рассказываю, как SLA помогает без лишних споров переживать такие моменты.  Меня зовут Эдуард, я руковожу отделом DevOps и отвечаю за сопровождение проектов по SLA 24/7. Хочу разобрать частую боль команд поддержки. Пока сервис работает стабильно, кажется, что […]

HEXACO: как ваши склонности определяют эффективность и почему выгорание начинается там, где вы играете чужую роль

Навыки можно прокачать за полгода. Склонности, которые формировались годами, либо работают на вас, либо разрушают карьеру. В IT это особенно заметно: джуниор с «правильной» архитектурой личности часто перегоняет мидла-перфекциониста, который каждое утро переписывает тесты, потому что «иначе не правильно». Если вы хотите не просто «где-то работать», а получать высокий доход и качество профессиональной жизни (КПЖ)

Если инцидент закрыт, это не значит, что проблема решена

Пятница, 23:40, прод лежит. Дежурный поднимает сервис за сорок минут: перезапустил контейнер, всё заработало. Инцидент закрыт, MTTR красивый, все спать. Через десять дней то же самое: тот же сервис, та же ошибка в логах. Снова подняли и снова закрыли. MTTR красивый, баг живой

Настроил ИИ-агента прямо в редакторе Zed: подключил Gemini и gopls, чтобы агент понимал код и реально помогал писать

За последние десять лет инструменты разработки существенно ускорили мою работу, но не изменили её сути: до недавних пор я тратил большую часть рабочего времени на написание кода и тестов. Но я смог это изменить, когда начал активно осваивать возможности ИИ. Меня зовут Александр Зайцев. Я Go-разработчик в команде Delivery компании «Флант» и работаю над werf и Deckhouse Delivery Kit (DevSecOps). […]

Организация производства Информационных систем. Часть 9. Современные подходы

Содержание курса Предмет исследования Варианты организации производства Жизненный цикл производства информационных систем Фаза: Предпроектное исследование. Предмет автоматизации Фаза: Предпроектное исследование. Предварительная оценка реализации Фаза: Проектирование, дизайн, формирование требований Фаза: 

DORA-метрики: как собирать, интерпретировать и не переусердствовать, часть 2

В первой части мы разобрали, как устроены DORA-метрики и что стоит за каждым из пяти показателей. Сложнее другое: одни используют их как инструмент улучшения процессов, другие – как универсальную шкалу зрелости. Разбираемся, почему контекст здесь важнее любого бенчмарка – и с чего начать команде, которая хочет считать метрики осмысленно. 

Как мы добавили ИИ-ассистента в рабочий чат и что из этого вышло

У нас небольшая IT-компания — SaaS-продукт, 5 разработчиков, 4 менеджера, CEO. Обычный стек: PHP + Vue, MySQL, GitHub, Telegram для коммуникации. Ничего революционного. Мы занимаемся автоматизацией бизнес-процессов. Но в какой-то момент поймали себя на мысли: мы автоматизируем чужие рабочие процессы, а свои — нет. Внутри компании всё держится на CEO, который вручную отвечает на вопросы, […]

Платформы разработки для самых маленьких и не только

Некоторое время назад я был участником команды, реализующей решение, на базе которого можно развернуть internal development platform. В первую очередь мы ориентировались на крупный enterprise с командами разработки от 150 человек, которым важны унификация, контроль, снижение когнитивной нагрузки на команды, безопасная разработка. Сегодня же хотел бы поделиться своими рассуждениями о платформах разработки немного под другим […]

Что такое DORA-метрики и как их измерять, часть 1

Проблема большинства команд не в том, что они работают медленно. Проблема в том, что они толком не понимают, где именно теряют время, сколько стоит каждая ошибка и насколько тяжёлым стал сам процесс поставки изменений. Именно здесь и полезны DORA-метрики. Разберём, что они измеряют, где их чаще всего трактуют неправильно и как применять их без KPI-магии. 

T-TOPS: Как распутать гордиев узел проекта после выхода в прод (меч не понадобится)

У каждого успешного Agile-проекта наступает момент, когда MVP перестаёт быть безопасной игрушкой для команды и попадает в руки реальных пользователей. Именно тогда заканчивается комфортная стадия и начинается новая проектная реальность. Сначала перемены почти незаметны. Владельцы продукта и маркетологи осторожно подправляют требования под рынок. Планы слегка качаются, но ещё держатся. Затем продуктовый аппетит растёт, однако развернуться […]

123.6