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

Меня зовут Сергей Павлов. Я разработчик, тимлид и CTO. Сейчас отвечаю за разработку продуктов в ИТ-экосистеме «Лукоморье». В этой статье я хочу помочь как разработчикам, так и начинающим руководителям увидеть обратную сторону управления.

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

Цель статьи простая: объяснить, почему человек, став руководителем, перестаёт думать только как разработчик. В его жизни появляются те самые «душные» штуки: метрики, бюджеты, приоритеты, риски, ресурсы и прочий управленческий слой. Этой статьёй я хочу объяснить логику управленца языком разработчика.

P.S. После прочтения есть высокий риск перестать быть «своим парнем» и начать работать на результат. Вы предупреждены.

---

#1: STAR — разговариваем на языке фактов, а не эмоций

#2: Security as Code: Безопасность — не ритуал, а процесс

#3: AI: Ваш новый тимлид-помощник (не заменяет, а усиливает)

#4: Баланс скорости, качества и стоимости: почему выбрать всё сразу не получится

#5: Язык бизнеса: Не «подняли кластер», а «сократили затраты на 15%»

#6: Cloud Native и Kubernetes: не «модно», а экономично и надёжно

#7: DevSecOps: Не тормоз, а двигатель

#8: Метрики: От тактики к стратегии и здоровью команды

#9: Философия настоящего IT-руководителя

Заключение

---

Всем Hello World!

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

Представьте картину маслом:

Сидишь ты такой, идеально настроенный разработчик, говоришь на языке Гита и контейнеров. И тут приходит руководитель. Сыплет какими-то метриками, capacity, бюджетами, рисками, а потом добивает страшным словом CAPEX. Первая реакция вполне предсказуемая — мысленно послать всё это куда подальше, а вслух вежливо сказать: «Отстань, дай мне спокойно писать код».

Знакомо? Вот об этой невидимой, но очень раздражающей стене я и хочу поговорить.

Ну всё, погнали! Снимаю шляпу и перехожу к сути.

#1: STAR - разговариваем на языке фактов, а не эмоций

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

На смену им приходит язык STAR: Situation (ситуация), Task (задача), Action (действие), Result (результат). И довольно быстро становится понятно, что именно такого разговора от руководителя и ждут.

Я прекрасно понимаю, что это боль для разработчика. Особенно если ты привык к логике: «я всё и так понятно объяснил, а если меня не поняли — это уже не моя проблема». Но в управленческой реальности так не работает. Там важно не только, что ты сделал, но и как ты это объясняешь.

Разберём STAR на простом примере:

• Ситуация. В релизном цикле был хаос: деплой занимал два дня, откаты — ещё сутки.

• Задача. Нужно сократить доставки фичи до клиента с двух недель до одного дня.

• Действие. Внедрили CI/CD-пайплайн на GitLab, автоматизировали тесты, разбили монолит на два сервиса.

• Результат. Частота релизов выросла с одного раза в месяц до 20 в неделю, а время деплоя сократилось до 15 минут.

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

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

Если есть время и интерес, можно прочитать хорошую статью на эту тему. Если, так сказать «влом», то вот кратко: 

STAR структурирует мысль. А структурированную мысль легче оценить, проверить и сопоставить с целями бизнеса. Для бизнеса это язык ясности, а ясность почти всегда конвертируется в доверие. Именно в этом месте становится понятно, зачем все это вообще нужно.

Вот всё и встало на свои места.

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

На заметку: STAR — это инструмент для внешней коммуникации: с бизнесом, заказчиком, высшим руководством. Если же требовать таких отчётов по каждому чиху внутри команды, можно быстро утонуть в бюрократии. Поэтому важен баланс: инструмент полезен там, где он действительно помогает прояснить результат, а не просто усложняет жизнь.

#2: Security as Code: Безопасность — не ритуал, а процесс

Пожалуй, это один из самых раздражающих пунктов для разработчика, релиз-менеджера и вообще всех, кто отвечает за сроки. Особенно когда релиз уже почти уехал в прод, а тут внезапно всплывает очередной алерт и, конечно же, ровно в тот момент, когда никто его не ждал.

Вот что здесь важно понять: безопасность нельзя «добавить» в конце. Хотя, что тут скрывать, конечно можно, но надо приготовиться потом разгребать последствия: долго, больно, дорого и глубоко («деревянный бегемотик, который не делал бекапы»). 

Именно поэтому ИБ так часто воспринимают как стоп-фактор, который мешает команде выпустить релиз продукта. От безопасности подгорает у всех: у разработчиков, у владельца продукта, у релиз-менеджера, а потом и у бизнеса, который не понимает, почему команда не может «просто выкатить несколько задач в прод».

И когда ваш руководитель приходит в команду и начинает докапываться до процессов, требуя сделать их безопасными, это не обязательно попытка вставить палки в колеса. Скорее наоборот: это признак того, что он понимает идею Security as Code.

Суть в том, что безопасность не должна быть отдельным ритуалом где-то в конце процесса. Она должна быть встроена в саму ткань разработки так же органично, как тесты, CI/CD или код-ревью. 

Такой подход должен поддерживать автоматические проверки безопасности на протяжении всего жизненного цикла:

• контроль доступа;

• управление политиками;

• сканирование уязвимостей;

• тестирование безопасности.

Всего цикла, не только в конце! Ферштейн?

Причём здесь не нужно изобретать велосипед. Уже есть инструменты, которые позволяют автоматизировать такие проверки: например, Checkov, CloudSploit, Terafirma (очень рекомендую заглянуть сюда, но учтите: сайтец не на кириллице). 

Эти тулзы — не помеха разработке, не специальный груз для увеличения сроков поставки изменений и тем более не заноза плохому разработчику в тот самый кривой палец, которым он накакодил, а именно усиление надежности и качества продукта! 

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

Если совсем приземлить пользу такого подхода, она очевидна для обеих сторон. Для руководителя Security as Code снижает зависимость от человеческого фактора и превращает безопасность из субъективной экспертизы в повторяемую, прозрачную и проверяемую практику. 

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

Как в самых лучших сериалах, вернёмся к тому, что обсуждали, чуть позже. To be continued … 

Ниже будет раздел DevSecOps именно для того, чтобы эту тему развернуть ещё шире.

#3: AI: Ваш новый тимлид-помощник (не заменяет, а усиливает)

«Gingers have no souls» — громко кричит айтишник своему руководителю!

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

На самом деле всё устроено иначе: грамотный руководитель не хочет заменить живых бойцов «железяками». Но и игнорировать ИИ сегодня — значит отставать от современной скорости разработки. Как с любым другим инструментом, здесь важно не перегнуть. Речь об усилении людей и снятии с них части нагрузки.

И если начальство просит внедрить ИИ, АИ, АИ-92, АИ-95 и так далее, не стоит автоматически воспринимать это как очередную модную галочку. У такого решения есть вполне прикладной смысл, и, что важно, польза здесь разная для команды и для руководителя.

Для команды ИИ — это способ снять часть рутины. Он может помогать с генерацией шаблонного кода, автоматическим созданием юнит-тестов, рефакторингом, анализом уязвимостей в коде (например, SonarQube с AI), анализом логов для поиска аномалий. Проще говоря, брать на себя те куски работы, где важны скорость, масштаб и первичная обработка данных.

Для руководителя ценность другая: ИИ помогает автоматизировать отчетность, быстрее собирать текст по метрикам, анализировать большие массивы обратной связи, видеть риски в проекте и не тратить часы на ручной разбор длинных обсуждений, чатов и созвонов. То есть он становится инструментом ускорения и навигации.

Простой пример — вместо того чтобы неделю рыться в терабайтах логов, инженер задаёт вопрос ИИ-ассистенту: «Покажи все инциденты за последний месяц, связанные с ростом памяти, и предложи вероятные причины». Через несколько минут он получает первичный анализ и набор гипотез.

Что это даёт? Экономию времени и нормальную отправную точку для дальнейшей работы. Но при этом ИИ не должен подменять инженерное мышление. Его ответ — не истина в последней инстанции, а заготовка, с которой дальше работает команда и руководитель. И следовать вслепую за советом машины, конечно же, глупо. Привет SkyNet, давай до свидания человечество, то самое 29 августа 1997 года.

Вывод — берёмся все дружно за руки: ИИ, разработка, руководство — и, как в доброй сказке про «По дороге с облаками (Cloud Native)», шагаем по дорожной карте из жёлтого кирпича. Главное — не превращать инструмент в религию и не делать вид, будто модель лучше понимает систему, чем команда, которая ее строит.

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

#4: Баланс скорости, качества и стоимости: почему выбрать всё сразу не получится

Есть классический треугольник управления разработкой: быстро, качественно, дёшево. 

И как ни крути, в чистом виде выбрать все три пункта одновременно не получается. Обычно можно получить только два из трёх. Это как математика, против которой бесполезно идти в атаку. Так уж устроен мир.

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

«Хочу, чтобы было быстро, качественно и дешево». Окей, принято, в таком случае могу посоветовать только «Доширак».

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

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

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

Стартап. Фокус на скорости. «Качество» здесь — это работоспособность ядра продукта и возможность быстро его менять. Техдолг приемлем, если он осознанный и задокументированный. 

Зрелый продукт. Фокус на качестве и стабильности. Скорость достигается за счет  отлаженных процессов, автоматизации и архитектурой. Каждый долг должен иметь план «погашения».

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

Как интересно получается, да? Двойные стандарты. Вот так!  Живите с этим :D

Ладно, шутки в сторону. Задача руководителя здесь довольно приземлённая: объяснить и бизнесу, и команде, почему в текущей фазе баланс смещён именно так, какие у этого решения ограничения и что произойдёт, если этот баланс нарушить.

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

#5: Язык бизнеса: Не «подняли кластер», а «сократили затраты на 15%»

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

Хороший ИТ-руководитель должен уметь говорить на языке бизнеса. Это не значит, что ему нужно внезапно начать разговаривать так со всеми подряд. Если сенсей начнёт общаться на «бизнесовом языке» с разработчиками, его закидают тапками и деклайнами на MR (на-ка выкуси, съел, да? MR — это тебе не шутки. Первое правило — дружи с теми, кто делает тебе ревью). 

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

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

Без примеров здесь не обойтись.

Фраза «мы внедрили кеширование» для бизнеса почти ничего не значит. Гораздо полезнее сказать: «Мы уменьшили время отклика системы на 70%. По результатам A/B-теста это может увеличить конверсию в оплату на 5%».

Или другой пример. Формулировка «мы переписали легаси-модуль» сама по себе не отвечает на вопрос, зачем это было нужно. А вот фраза «Мы снизили вероятность сбоев в критическом процессе на 90%, что защищает ежемесячную выручку в таком-то объёме» уже говорит с бизнесом на понятном ему языке.

Итого: умение общаться на языке бизнеса — это не занудство и не унижение разработчика, а способ выровнять понимание между теми, кто делает систему, и теми, кто оценивает её влияние на продукт и компанию.

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

#6: Cloud Native и Kubernetes: не «модно», а экономично и надёжно

Прежде чем идти дальше, можно отдельно почитать технический разбор темы. Но здесь я не хочу подробно останавливаться на софтверной стороне вопроса. Мне важнее донести другую мысль: Cloud Native и Kubernetes — это не про хайп. 

Когда бизнес слышит слова Kubernetes или Cloud Native, он часто воспринимает технологию как: «очередную модную игрушку девопсов, чтобы убивать время». 

И вот здесь задача ИТ-руководителя, который (надеюсь, что вам уже так не кажется) постоянно суёт свои руки в процессы разработки и поможет той самой dev-команде, потому что его задача перевести разговор из технической плоскости в бизнесовую: объяснить, как это влияет на деньги, скорость, надёжность и устойчивость продукта.

Упрощу до бытового примера, чтобы понять могла даже та самая тётя из бухгалтерии: переход на Cloud Native — это как замена конвейерного завода начала XX века на гибкое роботизированное производство. Те же станки, но совершенно другая эффективность.

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

Первый сценарий — скорость масштабирования. Реакция на нагрузку должна занимать минуты, а не дни.

К вашему продукту приходит ожидаемая нагрузка, например, «Чёрная пятница», период налоговых выплат, международные праздники или любая другая сезонная активность. Может быть и неожиданная нагрузка: кто-то запостил ссылку на продукт в крупном канале или соцсети, и пользователи массово кинулись смотреть, что там такое.

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

Вспомните серию из «Силиконовой долины», где герои через стену тащили коммуникационные провода между серверными стойками? Это было круто, но…не продуктивно!

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

В Cloud Native-среде картина другая. При заранее настроенном автоматическом масштабировании из-за роста нагрузки на CPU, память и так далее кубер сам запускает ещё десять копий вашего сервиса. Если ресурсов не хватает, платформа запрашивает новые виртуальные машины, и они появляются за минуты.

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

Второй сценарий — эффективность использования ресурсов, то есть экономия за счет отсутствия простоя.

Кто не сталкивался с типичной проблемой «зоопарка технологий»? Если такие люди есть, я даже не знаю, завидовать им или сочувствовать. С одной стороны, у них впереди очень интересный опыт, а с другой — приятного мало.

Представим инфраструктуру: куча серверов или виртуалок. На одной крутится БД, но простаивает 70% мощностей, на другой — веб-сервер, который перегружен и упирается в производительность. Получается, у нас есть «замороженные» ресурсы и нехватка ресурсов одновременно. А если всё это развёрнуто в облаках, компания ещё и платит за неиспользуемые мощности.

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

Когда сервис А потребляет мало CPU, оркестратор подселит к нему сервисы Б, В и так далее. Конечно, с учётом ограничений, чтобы они не мешали друг другу. На выходе CAPEX/OPEX снижается: нужно меньше серверов, инфраструктура становится легче и управляемее.

Третий сценарий — единая платформа. Больше никаких «на моей машине работает».

Вечная боль: разработчик говорит «У меня всё работает!». Девопс или админ с легкой ноткой матерка: «А на проде — нет!». Причина часто банальна: окружения отличаются. Версии библиотек, настройки ОС, конфигурации, креды, сетевые правила — и вот уже команда разбирает не бизнес-логику, а вопрос «как мы вообще до такого дошли».

Cloud Native-подход и оркестрация помогают ввести понятие единой платформы. Разработчику можно поднять в любом окружении, даже на личном ПК, конфигурацию, максимально близкую к продовой. Конечно, с другими параметрами подключения к базе и другими кредами, но по принципу работы окружения становятся похожими.

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

Кстати, держите совет, как это продать выше — держателям бюджета или в целом бизнесу:

«Мы предлагаем перейти на Cloud Native-платформу. Это позволит нам сэкономить до 30% на облаках за счет эффективной упаковки сервисов и использования ресурсов инфраструктуры, быстрее реагировать на рост нагрузки, снижать зависимость от конкретного поставщика и ускорять разработку за счет единых окружений и более стабильной платформы. Да, это требует инвестиций в компетенции и перестройку подходов, но окупается за счет скорости, надёжности и гибкости».

#7: DevSecOps: не тормоз, а двигатель

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

Development, Security, Operations — подход, в котором безопасность (Security) становится ответственностью каждого участника на каждом этапе.

Уже слышу мысли читателя:

— И всё же, избавьте меня от этого, пожалуйста! Это только тормозит. Понимаешь? Тормозит, удлиняет, усложняет цикл разработки. 

Предлагаю вместе спуститься с небес (с AWS) на землю (Дедик). DevSecOps не должен тормозить разработку. Почему? Потому что проверки автоматизированы и встроены в пайплайн. По факту гораздо дороже и дольше чинить уязвимость на проде, чем найти её на этапе разработки, тестирования или сборки.

Вот и всё, логика и математика максимально простая.

Приведу классические этапы и плюсы такого подхода:

• Инфраструктура как код (IaC) + сканирование: 

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

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

• Программирование и статический анализ кода (SAST): 

Здесь безопасность включается прямо во время разработки. Больше нет «хомяк-хомяк и в продакшен». Под рукой должен быть список инструментов, примерно как у опытного механика набор необходимых крутилок, вертелок и затягивалок. Подглядеть инструменты можно, например, здесь. 

Но сразу кидаться всё настраивать, конечно, не надо. Для начала можно взять любой софт, который анализирует исходный код на предмет уязвимостей: SQL-инъекции, XSS, проблемы с буфером и всякие страшные штуки. 

Поделюсь моим личным условием для всех разработчиков — если бедолага допустил XSS или SQL-инъекцию — это серьёзный залёт, красный флаг и 20 ударов розгами. 

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

• Коммиты и анализ зависимостей (SCA): 

Один из самых недооценённых рисков — сторонние библиотеки. Мы можем писать свой код аккуратно, но в проекте всё равно остаются зависимости, в которых регулярно обнаруживаются новые уязвимости. 

Поэтому на этапе коммита или в CI-пайплайне важно автоматически сканировать зависимости на известные проблемы. Хорошие инструменты здесь не только находят риск, но и помогают его исправить: например, автоматически предлагают обновление уязвимой библиотеки до безопасной версии. Опять же, всё зависит от выбора инструментов. Я бы посоветовал посмотреть на Snyk или WhiteSource (сейчас Mend.io). Просканировал стороннюю либу — спи спокойно. 

• Тестирование и динамический анализ (DAST). 

Если SAST смотрит на исходный код, то DAST проверяет уже работающее приложение. Выключаем в себе горе-хакера, и доверяем это дело проверенным программам, которые атакуют запущенное тестовое приложение, именно так, как бы это сделал хакер, настоящий, а не сын маминой подруги. 

Программа ищет слабые места во взаимодействии компонентов, настройках, обработке запросов и общей логике системы. Именно поэтому DAST не заменяет SAST, а дополняет его. Один подход ищет проблемы в коде, другой — в поведении уже собранной системы. В результате команда получает не только более надёжную проверку, но и что-то вроде облегчённого автоматизированного пентеста на тестовой среде. В таком случае релиз может катиться… главное, чтобы не куда подальше.

• Развертывание и проверка артефактов и контейнеров: 

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

Суть DevSecOps проста — найти и обезвредить проблему на самом раннем и дешёвом этапе. Для этого нужны не новые отделы, а правильные инструменты, встроенные в процесс, который мы и так каждый день делаем.

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

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

#8: Метрики: От тактики к стратегии и здоровью команды

Это тот момент, где мы переходим от ощущений в духе «команда вроде работает» к фактам: команда приносит бизнесу предсказуемую ценность. Когда ощущения будут не те, мы всегда это поймём, ведь теперь у нас будут метрики! 

Давайте разберём это как инструкцию по применению: почему тактические метрики обманчивы, как работают DORA-метрики и как их внедрить, чтобы они не стали «показателями ради показателей».

Velocity и BurnDown Chart — это метрики тактического уровня, одного спринта. Они показывают, успеваем ли мы сейчас, но не говорят, туда ли мы идём. И в этом как раз кроется частая ловушка для руководителя.

Представим спринт. Команда закрыла 100% задач. Velocity стабилен. Burndown Chart — идеальная прямая вниз. Всё выглядит прекрасно. Но что именно было сделано? Фича, которую пользователи ждали два года? Или перекрашена кнопка в пятидесяти местах? 

То есть Velocity измеряет количество работы, но не ценность (прикиньте, вы можете быть очень эффективными в производстве, но ценности от этого никакой). Burndown Chart показывает темп сжигания, но опять же не показывает, а правильные ли задачи горят (вы просто жарите по полной, сжигаете карточки, а вот нужные ли дровишки подкидываете в котёл — не факт). А если посмотреть с точки зрения бизнеса, то всё может быть печальнее, ведь достижение плана спринта прямо не означает достижения бизнес-цели.

Собираем свой дашборд из DORA-метрик (DevOps Research and Assessment):

DORA — это подход, который позволяет объективно оценивать эффективность разработки и находить узкие места в процессах. 

Deployment Frequency (Частота поставок): 

Эта метрика отвечает на вопрос: как часто мы доставляем ценность пользователю? Не сколько раз запускали пайплайн, а сколько раз пользователь реально получил новую функциональность: раз в день, в неделю, в месяц.

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

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

Почему это стратегически важно? Выкатка раз в месяц означает, что решения бизнеса реализуются с задержкой в месяц, а в digital-среде, где конкуренты делают A/B-тесты ежедневно, вы проигрываете ещё до старта. И цель — сделать деплой таким, чтобы он перестал быть событием.

Lead Time for Changes (Время от коммита до прода): 

Здесь важно не путать технический Lead Time с Lead Time в Jira, то есть временем от создания задачи до закрытия. DORA говорит о времени от появления изменения в коде до момента, когда оно реально работает у пользователя. И чем этот интервал короче, тем лучше.

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

Теперь понимаете, почему руководители-начальники лезут в процессы разработки? Какие-то метрики им засовывают, что-то просят считать… ааааа… да ну их!

Так вот:

• Lead Time for Changes меньше часа: Вы — Джон Уик! У вас идеальный, полностью автоматизированный пайплайн. Код уезжает практически сразу, а на пятничных посиделках в баре вы сидите за одним столом с ребятами, например, из Netflix, Google, Amazon и так далее. 

• Lead Time for Changes от одного дня до недели: Вы — Питер Бенджамин Паркер! У вас классическая ситуация, где есть автоматизация, но есть и ручные ворота в виде QA и Code Review, и всякие там деплои на прод руками. 

• Lead Time for Changes от одного месяца до полугода: Вы — … ценный кадр, однако живёте в релизном аду, где код пишется, потом лежит, потом сливается, потом его заб(и/ы)вают. И это прямой путь к техдолгу и демотивации.

Частота деплоя х Размер изменения = Lead Time. И чтобы сократить Lead Time, надо либо делать очень маленькие изменения, либо автоматизировать всё. И именно поэтому в процессы постоянно залезают сверху, пытаясь что-то поменять.

Change Failure Rate (Процент неудачных изменений):

Это доля релизов или деплоев, которые привели к инциденту и потребовали исправления: отката, хотфикса, патча или другой аварийной реакции.

Добавляя такую метрику, руководитель оценивает уверенность и предсказуемость ИТ. Если CFR растёт, бизнес начинает тормозить релизы, а это тянет за собой увеличение Lead Time, ну а дальше сами понимаете. 

Конечно, всё логично, но существует даже некий парадокс DORA, когда команды деплоят чаще, но ломают прод реже. Как? Они деплоят маленькие изменения с хорошими тестами и умеют быстро откатываться. Эти команды живут вот с таким нудным руководителями, вечно сующими свои странные идеи и хотелки в процессы разработки. 

Формула этого успеха довольно проста: (Релизы с ошибками / Количество релизов) х 100%

Мне страшно вам говорить правду, но посмотрите на градацию:

• 0–15%: Отлично. Ваши процессы надёжны.

• 15–30%: Терпимо, но есть куда расти. Возможно, недостаточно тестов или слабый мониторинг.

• > 30%: Вы постоянно ломаете прод. Команда живет в режиме «пожара». Доверие бизнеса к IT стремится к нулю.

Mean Time to Recovery (Среднее время восстановления): 

Одна из метрик, которая заставляет разработчиков и эксплуатацию краснеть. Как быстро мы чиним сломанное? 

Даже формулу нет смысла обсуждать — пользуемся здравым смыслом. И вспоминаем, как к нам сверху приходили с установками внедрить ранбуки, фича-тоглы (которые вечно копятся и распухают код), мониторинги, и сценарии откатов на каждый релиз! Наверняка кто-то уже морщился от фразы: «А где сценарий отката? Почему не написан?»

Хочу сказать, что MTTR — это не плюсик в самооценку IT-руководителя. Это плюс в карму всей команде разработки. Низкий показатель этой метрики показывает бизнесу: ошибки случаются, но команда умеет быстро их чинить.

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

Се ля ви. 

Открою небольшой секрет: качественный MTTR прямо влияет на Deployment Frequency. Вы не боитесь деплоить, потому что знаете — если что, откатим за минуту! Вот такой сюрприз, всё связано. 

Итак, что мы имеем. DORA — это индикатор здоровья IT-команды. Высокие показатели по всем четырём — признак высокопроизводительной команды. Про этот подход можно рассказывать долго, и это тема для отдельной статьи. Здесь оставлю краткий ориентир.

Квадрант DORA

Некий P.S. по DORA: если сама концепция зацепила и хочется посмотреть на метрики чуть шире, то предлагаю ознакомиться вот с этой статьёй. В ней представлен альтернативный подход к метрикам и хорошо объясняется, что нужно доработать напильником после применения.

#9: Философия настоящего IT-руководителя

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

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

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

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

Работа с техдолгом — такой же процесс, как и разработка новой функциональности. Его тоже надо измерять, планировать и прогнозировать.

Заключение

Итак, быть ИТ-руководителем — это не про то, чтобы перестать кодить и начать ходить на совещания, придумывая сложности для разработки. Не про месть за свои годы боли, когда разработчика вместо кода заставляли писать документацию… 

Быть ИТ-руководителем — это про смену парадигмы: с «создания кода» на «создание среды, в которой код превращается в бизнес-ценность».

Эту мысль не всегда просто принять. А когда вы видите, как благодаря выстроенным грамотным процессам команда быстро, безопасно и с удовольствием доставляет фичи, которые приносят компании миллионы, то вы понимаете, что «Я б руководителем пошёл — пусть меня научат».

Перед занавесом я подсвечу ещё раз, что, по моему мнению, — это далеко не полный список инструментов, которые помогают наладить мост между «кодерами» и «бизнесом». С удовольствием послушаю, кто какие использует. Может, у вас есть какие-то личные наработки. Также интересно узнать, у кого какие метрики реально работают, а какие только пылятся на дашбордах. Накиньте [на вентилятор] комментарии.

С каким? Или каким вы бы сами руководителем хотели быть? Выбирать вам!

Adios!