Главный принцип: надёжность — ваша общая с IT ответственность, а не только их проблема.

1. Заложите надёжность в разработку
— 40–60% инцидентов случаются после выпуска новой фичи.
— Внедряйте CI/CD, постепенный rollout и адекватные тестовые среды.
— Выделяйте 20–30% бэклога на техдолг и задачи надёжности — это страховка от будущих аварий.

2. Переходите на end-to-end команды
— Команда, которая разрабатывает и сопровождает сервис, выводит продукты на рынок быстрее и создаёт более устойчивые решения.

3. Требуйте настоящей наблюдаемости (Observability)
— Панель мониторинга должна за 30 сек. давать ответ: что сломалось, на кого влияет, какая бизнес-метрика падает.
— Фиксируйте целевые показатели доступности (SLO) ещё на этапе проектирования сервиса.

4. Управляйте технологическими рисками:
— Риск = Вероятность сбоя × Стоимость минуты простоя.
— Для критичных систем считайте классы критичности. Пример: «4 девятки» (99,99%) = десятки минут простоя в год.
— Регулярно проводите учения по аварийному восстановлению (DRP).
— Выстройте процесс управления мощностями

5. Ваша роль — расставлять приоритеты и давать команде время на улучшение фундамента.
— Защищайте команду от перегрузки. В спринте держите баланс: фичи, задачи на надёжность (20–30%), буфер на срочные правки (15–20%).


6. Задавайте правильные вопросы при выборе решений

1. Оценили ли риски?
2. Сколько стоит минута простоя?
3. Какое время восстановления (RTO) и потери данных (RPO)?
4. Что будет, если эта новая технология (например, AI-агент) перестанет работать?
5. Какие метрики выводятся на панель дежурным?
6. Когда пройдут первые аварийные учения?
7. Кто в команде отвечает за надёжность?

Итог: Управляйте надёжностью проактивно, говорите с IT на одном языке. Это не технические детали, а управленческие решения, которые напрямую влияют на лояльность клиентов и доход.

1. Жёлтая лампочка/стрелка на 0 — это WARNING в вашем Grafana/Zabbix: «Свободной памяти < 10%», «Диск заполнен на 85%».

2. Мысль «Заправлюсь утром» — это «Пофиксим в понедельник», «Это же не Critical, подождёт».

3. Ночной мороз и автозапуск — это внезапный всплеск трафика, фоновое задание, обновление — любая рядовая нагрузка, которая добивает иссякающий ресурс.

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

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

Мораль простая 😉

⚠️ Сигналы мониторинга существуют не для галочки. Они — прямой аналог датчиков в автомобиле. Игнорируя «жёлтые» алерты, вы гарантированно получаете «красный» инцидент в самый неподходящий момент.

Например, в парке, рядом с домом очень хорошо чистят дорожки от снега, действительно чисто, но есть одно НО… если чисто, то снегоуборочная техника все равно ездит по маршруту «в холостую», потому что в ней стоят gps трекеры и простоев быть не должно… (вот такой SLI - отсутствие простоев). Казалось бы SLА - выполнены, мэрия довольна, SLO тоже - чистят оперативно, даже через чур… а вот индикатор (SLI) не верный… в итоге дополнительные расходы… а могли бы чистить в другом месте, там где это действительно нужно.

Ускорение задач → Рост ожиданий скорости → Зависимость от ИИ → Расширение функционала → Увеличение плотности работы → Когнитивное истощение

ИИ сам по себе не снижает нагрузку, а позволяет делать больше.

Чтобы это не привело к выгоранию и снижению качества, организациям нужно активно формировать такие практики:

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

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

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

- Четкая последовательность. Вместо мгновенной реакции — сбор и групповая обработка результатов работы ИИ в отведенные временные слоты. Это освобождает ресурсы для глубокой фокусировки

- Человеческое общение!... Выделение времени для живого общения: в отличие от ответов ИИ, диалог с коллегами возвращает контекст и выявляет неочевидные нюансы.

Pre-mortem — это гипотетическая противоположность посмертного анализа (postmortem). В медицине вскрытие позволяет медикам и родственникам узнать, что стало причиной смерти пациента.

Выгоду получают все, кроме, разумеется, самого пациента. Pre-mortem в IT/Бизнесе проводится в начале проекта, чтобы его можно было улучшить, а не «вскрывать».

В отличие от типичных сессий критики, где членов команды/AI-агентов спрашивают, что может пойти не так, Pre-mortem исходит из предположения, что «пациент» умер, и задает вопрос: что именно пошло не так?

Задача команды/AI-агентов — придумать правдоподобные причины провала проекта/внедрения.

Здесь соберутся более 2000 участников (и онлайн-зрителей): разработчики, специалисты по контенту и коммуникациям, HR, а также руководители и собственники IT-компаний.

В течение двух дней – мощный IT-буст:
- 200+ докладов от лидеров индустрии из ВКонтакте, Авито, Яндекса, Сбера, Wildberries & Russ, Ozon, Газпром ИД, Альфа-Банка и т.д.
- 30+ секций по четырём направлениям: Разработка, Управление, Дизайн и Контент, Digital-маркетинг.
- мастермайнды, панельные дискуссии, мастер-классы, экспертные зоны, нетворкинг-события, афтепати в завершении первого дня.

- К 2028 году компании с грамотно настроенным harness будут иметь на 60% меньше дефектов после запуска продукта

- Правильная инфраструктура повышает успешность генерации кода с 53,8% до 81,8%

- Разница между топовыми моделями ИИ при этом невелика - всего 1–3%.

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

Берлинский разработчик Амин Боргеи создал на основе этой техники готовый скилл Premortem для Claude. Он собирает контекст из чатов и файлов, реконструирует сценарии провала, поручает сгенерированным «следователям» проанализировать каждый из них и выдает чеклист на 3–5 пунктов — что
надо было проверить до запуска

ссылка