Уровень ИТ зрелости

5 уровней зрелости ИТ

УРОВЕНЬ 0 ЗРЕЛОСТИ IT: CHAOS AND SURVIVAL MODE

Введение

Привет, Хабр! Сегодня начинаем долгий и подробный разбор уровней зрелости IT-организации. Это не просто теория — это практический гайд для CTO, IT-директоров и руководителей, которые хотят понять, где сейчас находится их компания и как двигаться вперёд.

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

Что такое Level 0?

Level 0 — это состояние, когда IT-процессы отсутствуют, а выживание — единственная цель. На Level 0:

• Нет документации процессов

• Нет планирования проектов

• Нет версионирования кода (или есть, но никто не знает, как им пользоваться)

• Нет тестирования (или тестирование исключительно ручное и хаотичное)

• Нет мониторинга (узнали о проблеме, когда упало всё)

• Люди работают на "heroics" — срочно исправляют то, что сломалось

Характеристики Level 0

1. Полная непредсказуемость

На Level 0 никто не знает:

• Сколько времени займёт проект (может быть неделя, может быть полгода)

• Сколько это будет стоить (бюджет постоянно превышается)

• Когда проект будет готов (дедлайны — это фантастика)

• Будет ли это работать в production (часто не работает)

Пример: Компания обещает CEO запустить новый продукт за 3 месяца. Проходит 3 месяца. Продукт на 30% готов. Все удивлены, что неправильно рассчитали.

Проходит ещё 3 месяца. Продукт на 70% готов. Но появились новые ошибки в уже готовых частях.

Проходит ещё 3 месяца. Наконец запустили. Но в production обнаружилась крит��чная ошибка, которую никто не видел на development.

Итого: вместо 3 месяцев понадобилось 9. И бюджет превышен в 3 раза.

2. Люди как героев

На Level 0 компания зависит от одного-двух гениальных инженеров, которые знают "всё":

• Где лежит код (может быть в GitHub, может быть на чьём-то ноутбуке, может быть просто в памяти)

• Как это развернуть (может быть есть документация, может быть нет, спросите Сашу, он знает)

• Почему это работает (никто не знает, но работает)

Если эти инженеры уходят, компания теряет критичные знания. Может быть, даже потеряет доступ к production.

Пример: Senior разработчик Иван ушёл из компании. Никто не знает пароль от production сервера. Никто не знает, как развернуть приложение. Никто не знает, где хранится код.

Для восстановления знаний потребовалось:

1. Звонить Ивану и просить пароли (неловко)

2. Пересчитать файлы на сервере (2 недели)

3. Восстановить процесс развёртывания (1 месяц)

Итого: один месяц компания не могла выпустить ни одного обновления.

3. Отсутствие тестирования (или тестирование "руками")

На Level 0 тестирование выглядит так:

• Разработчик написал код

• Разработчик сам его протестировал в браузере (кликнул несколько кнопок)

• "Выглядит работает, отправляем в production!"

В production обнаружилась ошибка:

• Если нажать кнопку два раза подряд, приложение крашится

• Если интернет медленный, форма не отправляется

• Если пользователь на мобильном устройстве, интерфейс сломан

Никто этого не видел, потому что никто не тестировал эти сценарии.

Результат: production постоянно в огне. Каждый день новая ошибка.

4. Отсутствие мониторинга

На Level 0 мониторинг — это когда пользователи звонят и говорят "У меня не работает".

• "Уже два часа не работает?" — "Да, с двух часов ночи."

• "Почему никто не заметил раньше?" — "Потому что все спали."

Типичная история:

• 02:00 - Сервис упал

• 02:00-08:00 - Никто не знает (все спят)

• 08:00 - Клиент звонит и говорит "У меня не работает ваш продукт"

• 08:10 - IT узнает о проблеме

• 08:30 - Начали расследование ("Что произошло?")

• 09:00 - Нашли проблему (закончилась память на диске)

• 09:30 - Чистили диск

• 10:00 - Сервис восстановили

Итого: 8 часов downtime, потери в миллионы рублей, клиенты в ярости.

5. Версионирование кода — хаос

На Level 0 версионирование кода выглядит так:

• code.zip

• code_v2.zip

• code_v2_final.zip

• code_v2_final_REAL.zip

• code_v2_final_REAL_used_this_one.zip

Никто не знает, какая версия в production. Когда что-то ломается, никто не знает, когда это сломалось и что изменилось.

Попытка откатить изменения? Невозможно, потому что непонятно, какие файлы изменились.

Типичный диалог:

• "Когда это перестало работать?"

• "Примерно неделю назад"

• "Давай откатимся на неделю назад"

• "А какая была версия неделю назад?"

• "Не знаю... может быть, code_v2_final.zip?"

• "Это же не сработает, потому что там другой код для другого модуля"

Результат: потребовалось 2 дня, чтобы разобраться, что сломалось, и пришлось просто переписать код с нуля.

Финансовый и бизнес-эффект Level 0

Потерянные инвестиции в IT

На Level 0 компания вложила, скажем, 100 млн ₽ в IT за год. Но видимый ROI? Почти нулевой.

Почему? Потому что большинство денег уходит на:

• Тушение пожаров (починка экстренных ошибок, overtime, срочные деплойменты)

• Переделки (сделано, но нужно переделать, потому что непонятны требования)

• Downtime (потери от простоев)

• Потери клиентов (они уходят из-за постоянных ошибок)

На самом деле, только 10-20% бюджета идёт на разработку новых фич, которые приносят бизнесу ценность.

Потери от downtime

На Level 0 downtime может быть 5-10% в год (18-36 дней в году без доступа к сервису).

Если компания зарабатывает 1 млрд ₽ в год, и это зависит от онлайн-сервиса, то 5% downtime = 50 млн ₽ потерь в год.

К этому добавьте:

• Потери от переходов клиентов к конкурентам

• Штрафы от партнёров (если это B2B)

• Репутационные потери

Невозможность конкурировать

Конкурент на Level 3 может выпустить новую фичу за 2 месяца.

Вы на Level 0 выпускаете новую фичу за 6-9 месяцев.

За это время конкурент уже выпустил 5 фич. Клиенты видят, что конкурент лучше, и переходят к нему.

Результат: вы теряете рынок.

Кто на Level 0?

Честно говоря, многие компании на Level 0, но не все это признают. Типичные примеры:

Стартапы с быстрым ростом

• Начало: 5 разработчиков, они просто кодят

• Через 6 месяцев: 20 разработчиков, но процессы не изменились

• Результат: chaos, никто не знает, что делает другой

Компании, которые переживали быстрый рост

• Были на Level 2-3, но потом быстро выросли (10x пользователей, 10x разработчиков)

• Процессы не масштабировались

• Вернулись к Level 0

Фамильные бизнесы

• Основатель говорит "Я сам знаю, как всё работает, зачем нам процессы?"

• Когда основатель уходит, всё разваливается

Компании на технологиях 10-летней давности

• Старый код никто не понимает

• Документация потеряна или устарела

• Никто не знает, зачем нужен код

Симптомы Level 0

Вот признаки, по которым можно понять, что компания на Level 0:

Постоянные срывы сроков

• Любой проект занимает в 2-3 раза дольше, чем планировалось

• Никто не удивлен, это норма

Частые production инциденты

• Несколько раз в неделю что-то ломается

• Люди работают по ночам, чтобы чинить

Нет планирования

• На встречах спорят о том, какие функции нужны (и спорят каждый раз заново)

• Нет written requirements (всё в голове или на бумажке)

Люди работают на эмоциях

• "Это срочно, нужно сегодня!"

• "Это критично, работайте до ночи!"

• Люди выгорают за 1-2 года

Высокая текучка в IT-отделе

• Хорошие разработчики уходят (им надоел chaos)

• Остаются только те, кто не может найти другую работу

• Новые люди не интегрируются, потому что нет процессов

Невозможно найти информацию

• Где хранится документация? Не знаем.

• Где код? На чьём-то ноутбуке? На GitHub? На сервере?

• Как развернуть? Спросите Сашу.

Бизнес разочарован в IT

• "IT слишком медленная"

• "IT всегда срывает сроки"

• "IT не понимает бизнес"

• "Может быть, нам нужна другая компания?"

Путь из Level 0

Выход из Level 0 — это не одна большая реформа, а серия маленьких шагов. Обычно это занимает 6-12 месяцев.

Шаг 1: Документирование текущего состояния

Первое — нужно понять, что у вас есть:

• Где хранится код?

• Как развернуть приложение?

• Какие системы есть?

• Кто за что отвечает?

Это звучит просто, но это может занять 2-4 недели.

Шаг 2: Базовое версионирование кода

• Все файлы кода должны быть в Git (GitHub, GitLab или локальный GitLab)

• Каждый коммит должен иметь описание, что изменилось

• Должна быть история изменений (кто, когда, что изменил)

Результат: при проблеме можно откатиться на любую версию. Люди видят историю изменений.

Шаг 3: Базовое планирование проектов

• Использовать какую-то систему для отслеживания задач (Jira, Trello, даже Google Sheets)

• Каждый спринт (неделя или две) планировать задачи на спринт

• Отслеживать прогресс

Результат: понимание, где мы, где мы хотим быть, сколько это займёт.

Шаг 4: Базовое тестирование

• Разработчик пишет код

• Тестировщик (или другой разработчик) проверяет на ошибки

• Тестовые сценарии документируются

Результат: меньше ошибок в production (может быть, не 50% меньше, но заметно меньше).

Шаг 5: Базовый мониторинг

• На сервере включить логирование (что происходит)

• Настроить alerts (если что-то плохое, отправить email/SMS)

• Один человек проверяет логи каждое утро

Результат: узнавать о проблемах раньше, чем они станут критичными.

Выводы

Level 0 — это не приговор, это стартовая точка.

Многие компании начинали на Level 0. Некоторые всё ещё там и не знают, как выбраться. Но те, кто понял, что нужно меняться, могут достичь Level 1-2 за год.

Главное правило: не пытайтесь прыгнуть сразу на Level 3 или 4. Начните с базовых процессов (документация, версионирование, планирование, тестирование, мониторинг).

Когда эти процессы станут нормой (через 6-12 месяцев), вы готовы к Level 1.

Level 1 — когда появляются первые процессы, но всё ещё много ручного труда и рисков.

Введение

На Level 0 IT была как дикий запад — никаких правил, никаких процессов, полный chaos.

На Level 1 ситуация начинает улучшаться. Появляются первые процессы. Люди начинают документировать, что они делают. Начинает казаться, что IT — это не просто "работайте по ночам и чините ошибки", а реальная дисциплина.

Но не спешите радоваться. Level 1 — это самое опасное место, потому что компания думает "Ура, у нас есть процессы!" и останавливается. На самом деле, это только начало.

Что такое Level 1?

Level 1 — это состояние, когда есть базовые процессы, которые иногда повторяются, но нет культуры их соблюдения. Люди знают, "как правильно", но часто не делают этого, потому что нет контроля и штрафов.

На Level 1:

• Процессы задокументированы (написано, как делать)

• Есть версионирование кода (Git)

• Есть планирование проектов (Jira или Trello)

• Есть базовое тестирование (QA отдел или QA люди)

• Есть базовый мониторинг (логи, alerts)

• Но всё зависит от людей (если нужно, люди могут пропустить процесс)

Ключевые характеристики Level 1

1. Процессы задокументированы, но не всегда следуются

На Level 1 есть документация:

• "Как правильно разработать фичу?" — есть wiki

• "Как правильно развернуть в production?" — есть run-book

• "Как тестировать?" — есть чек-лист

Но что происходит на практике?

Сценарий 1: Срочный фикс

• "Критичная ошибка в production, нужно фиксить сейчас!"

• "Но нам нужно следовать процессу: code review, тестирование, approval..."

• "Нет времени, мир горит! Просто фиксим и выкатываем!"

• Разработчик напрямую коммитит в master ветку, пропускает code review

• Выкатывает в production без тестирования

• (80% вероятности) внедрил новую ошибку вместе с ф��ксом

Сценарий 2: Давление дедлайна

• Project deadline — два дня

• "Нам нужно пропустить тестирование, чтобы успеть"

• "Но процесс требует тестирования..."

• "Мы его потом протестируем!"

• (95% вероятности) потом никогда не протестируют

• (80% вероятности) в production найдутся ошибки

Результат: процессы есть, но они используются только когда "есть время". Когда срочно, люди берут и игнорируют процессы.

2. Есть роли, но нет ответственности

На Level 1 есть люди с названиями ролей:

• QA Engineer (занимается тестированием)

• DevOps Engineer (занимается развёртыванием)

• Tech Lead (отвечает за архитектуру)

Но нет чёткой ответственности:

• "Кто отвечает, если проект задержится?" — "Ну, это бизнес не рассчитал, это QA медленно тестирует, это DevOps долго разворачивает"

• "Кто отвечает, если в production обнаружится ошибка?" — "Это разработчик её не заметил, это QA её не поймала, это DevOps неправильно развернул"

Результат: ответственность размывается. Все говорят "Это не я", и никто не берёт на себя ответственность за результат.

3. Метрики есть, но не анализируются

На Level 1 есть метрики:

• Сколько ошибок было обнаружено на тестировании?

• Сколько ошибок прошло в production?

• Сколько времени занял проект?

• Какой был downtime?

Но что происходит с этими метриками? Ничего.

Они собираются, может быть, заносятся в таблицу Excel, но никто не смотрит на тренды и не принимает решения на основе данны��.

Типичный диалог:

• "У нас слишком много ошибок в production"

• "Да, я вижу, было 150 ошибок в последнем месяце"

• "А что мы с этим будем делать?"

• "Ну... давайте попросим разработчиков быть аккуратнее?"

• (тишина)

• В следующем месяце снова 150 ошибок

Результат: метрики собираются, но не используются для улучшения.

4. IT имеет смутное понимание бизнес-целей

На Level 0 IT не думает о бизнесе. Просто кодит.

На Level 1 IT начинает думать о бизнесе, но понимание размытое и часто неправильное.

Типичный диалог:

• Бизнес: "Нам нужна новая система CRM"

• IT: "Отлично, давайте внедрим Salesforce"

• Бизнес: "Это будет стоить 50 млн ₽"

• IT: "О нет, это слишком дорого"

• Бизнес: "Почему слишком дорого? Это же просто система?"

• IT: "Потому что нужно интегрировать со всем, мигрировать данные, обучить людей..."

• Бизнес: "Можно дешевле?"

• IT: "Нет, это минимум 50 млн"

• Бизнес: "Ладно, но это займет сколько времени?"

• IT: "Ну... может быть, 6 месяцев?"

• Бизнес: "А может за 3 месяца?"

• IT: "Нет, 6 месяцев минимум"

• (Через 9 месяцев проект всё ещё не готов)

Результат: IT и бизнес не синхронизированы. IT говорит "это невозможно", бизнес говорит "это нужно срочно". Никто не может договориться.

5. Downtime всё ещё значительный

На Level 0 downtime был 5-10% в год.

На Level 1 downtime улучшился до 2-5% в год. Это, конечно, лучше, но всё ещё ужасно.

2% downtime = 7 дней в году без доступа к сервису.

Почему всё ещё так плохо?

• Нет автоматического восстановления (если сервер упал, нужно, чтобы человек заметил и исправил)

• Нет backup-ов или они не тестировались (потеря данных)

• Нет redundancy (если один компонент отказал, всё падает)

6. Проекты оцениваются "на глаз"

На Level 1 оценка времени для проекта выглядит так:

• Менеджер: "Сколько займет эта фича?"

• Разработчик: "Ну... похоже на то, что я делал месяц назад. Это было 2 недели. Но тут сложнее. Может быть, 3 недели?"

• Менеджер: "3 недели? Это много. Может быть, 2 недели?"

• Разработчик: "Нет, точно 3"

• Менеджер: "Попробуй за 2"

• (Через 4 недели разработчик говорит "Готово, но есть несколько bugs")

Результат: отклонение от плана ±50-100%. Никто не знает точно, насколько долго это займет.

Финансовый эффект Level 1

Улучшение, но всё ещё дорого

На Level 1 компания немного сэкономила по сравнению с Level 0:

• Downtime улучшилась с 10% до 3% (экономия ~30 млн ₽ в год для крупной компании)

• Ошибки в production снизились (потому что есть QA)

• Люди меньше работают по ночам (потому что есть базовый мониторинг)

Но всё ещё теряется:

• На переделках (70% проектов требуют переделки, потому что требования были непонятны)

• На срывах сроков (каждый второй проект задерживается на 1-2 месяца)

• На инцидентах в production (требуется срочное исправление, overtime, потеря клиентов)

Люди по-прежнему выгорают

Хотя вроде "есть процессы", люди всё ещё перегружены:

• Когда срочно, процессы игнорируются, и все работают по ночам

• QA работает под давлением дедлайнов

• DevOps занимается ручным развёртыванием и часто вызывается в 3 часа ночи

• Tech Lead разбирает конфликты между разработчиками

Результат: лучшие люди уходят. Остаются те, кто не может найти другую работу.

Типичные компании на Level 1

Выросшие стартапы (50-200 человек)

• Были на Level 0, наняли QA, DevOps, Tech Lead

• Процессы появились, но не укоренились в культуре

Компании с внешним давлением

• Клиент или инвестор потребовали "уметь показать процессы"

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

• Но люди внутри продолжают игнорировать эти процессы

Компании в переходе

• Новый CTO/IT-директор пытается внедрить процессы

• Старые люди сопротивляются ("Это замедляет нас!")

• Новые люди пытаются следовать процессам

• Результат: chaos, потому что половина следует, половина нет

Симптомы Level 1

Процессы есть, но люди их игнорируют

• Git есть, но люди иногда коммитят просто в master

• Code review есть, но иногда его пропускают "на срочное"

• Тестирование есть, но часто пропускают "на дедлайн"

Метрики собираются, но не анализируются

• Есть таблица с количеством ошибок, но никто не смотрит

• Есть график времени проектов, но никто не извлекает выводы

Постоянные "срочные"

• "Это срочно, нужно сегодня!"

• Люди начинают игнорировать процессы для "срочных"

• Каждый день что-то срочное

Conflicting messages

• Tech Lead говорит "Нужно следовать процессам"

• Manager говорит "Но дедлайн завтра, забыть про процессы"

• Разработчик не знает, что делать

Высокая текучка в рядах среднего звена

• Senior разработчики, QA, DevOps уходят из-за chaos

• Они уходят в компании, где есть нормальные процессы и культура

Путь из Level 1 к Level 2

Выход из Level 1 — это превращение процессов из документов в культуру. Это занимает 12-18 месяцев.

Шаг 1: Выбрать одного человека ответственным за IT-процессы

Это может быть:

• CTO (если его основная работа не была отвлечена на разработку)

• IT-директор

• Специальная роль "Engineering Manager" или "Process Manager"

Этот человек должен:

• Следить, что процессы соблюдаются

• Помогать людям, если они не понимают процесс

• Постоянно улучшать процессы на основе feedback

Результат: есть один человек, который "болеет" за процессы.

Шаг 2: Настроить автоматизацию, чтобы заставить соблюдать процессы

Примеры:

• Git branch protection: нельзя push в master без pull request

• CI/CD pipeline: код не может попасть в production без автоматических тестов

• Automated monitoring: если error rate > 5%, автоматически откатиться на предыдущую версию

Результат: даже если человек захочет пропустить процесс, система не даст.

Шаг 3: Установить метрики и обзорить их еженедельно

• Сколько ошибок было обнаружено на тестировании?

• Сколько ошибок прошло в production?

• Какой был average time to fix?

• Сколько downtime?

• Отклонение от оценки проекта?

Каждую неделю (или каждый спринт) обсуждать:

• Какой был прогресс?

• Что улучшилось?

• Что ухудшилось?

• Что мы будем делать по-другому?

Результат: люди видят, что метрики изменяются. Им показывают, что их действия имеют влияние.

Шаг 4: Обучить людей и новичков

Когда приходит новый разработчик на Level 1, его спрашивают:

• "Как здесь работает?"

• Он получает ответ: "Ну, примерно так..." (и каждый ему объясняет по-своему)

На Level 2 новый разработчик:

• Проходит onboarding (документированный процесс)

• Смотрит training видео (или читает wiki)

• Делает свой первый pull request с code review

• Видит, как работает CI/CD pipeline

Результат: новички быстрее интегрируются, меньше грубых ошибок.

Шаг 5: Создать культуру "правильное важнее, чем быстро"

Это самый сложный шаг, потому что нужно изменить мышление людей.

На Level 0-1 люди думают: "Главное — быстро выкатить. Если там ошибка, потом исправим."

На Level 2 люди должны думать: "Главное — правильно. Если это займет чуть дольше, но ошибок не будет — это лучше."

Как это внедрить?

• Когда разработчик предлагает пропустить тестирование "для скорости", его спрашивают: "Если мы этого не протестируем и в production найдется ошибка, это займет сколько времени на исправление?"

• Обычно ответ: "2-3 дня"

• "А тестирование займет?"

• "2-3 часа"

• "Тогда давайте потратим 3 часа на тестирование, чтобы не потратить 2-3 дня на фиксинг"

Результат: люди начинают видеть, что "правильно" часто == "быстро в долгосроке".

Выводы

Level 1 — это первый шаг, но очень важный.

Компания наконец признала, что нужны процессы. Компания написала документацию. Компания нанял людей на роли (QA, DevOps, Tech Lead).

Но это только начало. Level 1 — это как написать бизнес-план. Важно, но на этом не стоит останавливаться.

Главное различие между Level 1 и Level 2 — это культура и дисциплина. На Level 2 процессы соблюдаются не потому что "нужно", а потому что все видят, что это работает.

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

УРОВЕНЬ 2 ЗРЕЛОСТИ IT: MANAGED PROCESSES AND PREDICTABILITY

Введение

На Level 0 было полное отсутствие процессов. На Level 1 процессы появились, но люди их постоянно нарушали.

На Level 2 ситуация кардинально меняется. Процессы становятся нормой, а не исключением. Люди следуют им не потому что их заставляют, а потому что видят результаты. Проекты начинают заканчиваться близко к оценкам. Люди перестают работать по ночам каждый день.

Level 2 — это точка, где компания наконец может дышать спокойно. Это не конец пути, но это первый реальный прогресс.

Что такое Level 2?

Level 2 — это состояние, когда:

• Процессы всегда соблюдаются (технически невозможно их обойти)

• Проекты оцениваются более точно (отклонение ±20% вместо ±100%)

• Метрики используются для принятия решений

• Есть четкая ответственность за результаты

• Downtime снизился до 1-2% в год

• IT и бизнес начинают синхронизироваться

На Level 2:

• Code review — обязательно (система не даст коммитить без review)

• Тестирование — обязательно (автоматические тесты запускаются для каждого коммита)

• Развёртывание — контролируемое (есть process для каждого деплоя, всё логируется)

• Мониторинг — активный (система сама отправляет алерты при проблемах)

• Планирование — точное (оценки основаны на историческим данных)

Ключевые характеристики Level 2

1. Automation превращает процессы в неизбежность

На Level 1 процессы были на бумаге. На Level 2 процессы встроены в tooling.

Пример: Code Review

Level 1:

• Разработчик напрашивает документацию "Code Review Guidelines"

• Разработчик пушит код в branch

• (Иногда) другой разработчик ревьюит

• (Иногда) комментирует с обратной связью

• Разработчик мёржит в master

Problem: (иногда) code review пропускается на срочных.

Level 2:

• Git настроен так, что нельзя мёржить в master без 2 одобрений (approvals)

• Система автоматически запускает CI pipeline (автоматические тесты)

• Если тесты не прошли, мёржить невозможно

• Если нет approvals, мёржить невозможно

Результат: code review больше не опция, это MUST. Технически невозможно обойти.

Пример: Тестирование

Level 1:

• Разработчик пишет код

• QA тестирует (или не тестирует, если спешит)

• Если что-то прошло в production — потом чинят

Level 2:

• Разработчик пишет код + пишет unit тесты

• Git hook автоматически запускает тесты перед коммитом

• Если тесты не прошли, коммит не создается

• На CI/CD pipeline запускаются интеграционные тесты

• На staging окружении запускаются end-to-end тесты

• Только если все тесты прошли, возможен деплой в production

Результат: ошибки, которые должны быть поймана на тестировании, физически не могут попасть в production.

2. Metrics-driven decision making

На Level 1 метрики собирались, но не использовались.

На Level 2 метрики используются для каждого решения.

Пример 1: Проблема с качеством

Level 1:

• "У нас слишком много ошибок в production"

• "Давайте просим разработчиков быть осторожнее"

• (Ничего не меняется)

Level 2:

• Смотрим на данные: "Где больше всего ошибок? В модуле A или модуле B?"

• Данные говорят: "В модуле A в 3 раза больше ошибок"

• "Почему? Может быть, потому что модуль A сложнее или там плохие тесты?"

• Анализируем: "Тесты покрывают модуль A только на 40%, а модуль B на 80%"

• Решение: "Давайте увеличим coverage для модуля A до 80%"

• Через месяц: количество ошибок в модуле A снизилось на 70%

Результат: решение основано на данных, результат измеряется.

Пример 2: Проблема с временем проектов

Level 1:

• Проект занял 5 месяцев вместо планируемых 3

• "Ну, требования были неясны"

• (В следующем проекте история повторяется)

Level 2:

• Смотрим на данные за год: все ли проекты задерживаются?

• Данные: 80% проектов задерживаются на 1-2 месяца

• Анализируем: в чем причина?

  • 40% — неясные требования в начале

  • 30% — недооценка сложности

  • 20% — interruptions (внезапные critical fixes)

  • 10% — другое

• Решения:

  • Требования: ввести обязательную стадию "requirements clarification" перед оценкой

  • Сложность: ввести историческую базу данных оценок и сравнивать с похожими проектами

  • Interruptions: зарезервировать 20% capacity для срочных фиксов

• Через 3 месяца: 70% проектов соответствуют оценкам (вместо 20%)

Результат: проблемы решаются, потому что мы их измеряем и анализируем.

3. Четкая ответственность за результаты

На Level 1 ответственность размывалась. На Level 2 ответственность четкая.

Пример: Срыв проекта

Level 1:

• Проект сорвался на месяц

• Спрашиваем разработчиков: "Что случилось?"

• Разработчик: "Требования были неясны, я просил уточнение, но никто не помог"

• Спрашиваем менеджера: "Что случилось?"

• Менеджер: "Разработчик работал медленно, я просил ускориться, но он говорил, что требования неясны"

• Ответственность: каждый винит другого

• Следствие: никого не наказали, ничего не изменилось

Level 2:

• Проект планировался на 3 месяца

• До начала проекта:

  • Tech Lead обязуется "технически это возможно за 3 месяца"

  • Project Manager обязуется "требования будут поняты и зафиксированы"

  • Product Owner обязуется "resources будут выделены"

• Проект начинается

• После первого месяца: метрика, что 30% функциональности готово (в плане было 33%)

• После второго месяца: 65% готово (в плане 66%)

• Если что-то отстает, сразу видно: "Мы отстали на X%. Почему? Что нам нужно изменить?"

• Ответственность: конкретные люди отвечают за конкретные метрики

• Следствие: люди берут ответственность серьезнее

4. Планирование основано на историческом данных

На Level 1 оценка была "на глаз".

На Level 2 оценка основана на историческом данных.

Как это работает:

Шаг 1: Собрать исторические данные

• За последний год собираем все проекты

• Для каждого проекта: сложность, estimated time, actual time

• Простой проект (1-3 story points): average actual time 1 неделя

• Средний проект (5-8 story points): average actual time 3 недели

• Сложный проект (13+ story points): average actual time 8 недель

Шаг 2: Использовать эти данные для оценки

• Новый проект: "Это похоже на средний проект, 6-7 story points"

• Смотрим на историческую базу: средний проект = 3 недели average

• Оценка: 3 недели

Шаг 3: Отслеживать отклонения

• Проект заканчивается за 2.8 недели (в плане было 3 недели)

• Отклонение: -0.2 недели (0.7% отклонение, отлично)

• Добавляем в историческую базу: это подтверждает наш estimate

Результат: через год компания имеет базу из 100+ проектов, и оценки становятся очень точными (±10-20%).

5. Downtime снизился, люди не работают по ночам

На Level 1 downtime был 2-5% в год.

На Level 2 downtime снизился до 1-2% в год.

Как? Потому что есть:

• Автоматическое мониторинг (система видит проблему за секунды)

• Автоматическое восстановление (система пытается восстановиться сама)

• Redundancy (если один сервер упал, другой взял на себя)

• Backup и recovery процессы (тестируются регулярно)

Типичный инцидент на Level 1:

• 02:00 - Сервер упал

• 02:00-08:00 - Никто не знает

• 08:00 - Клиент позвонил

• 08:30 - Начали расследование

• 10:00 - Нашли проблему

• 11:00 - Исправили

• Итого: 9 часов downtime, overtime, люди без сна

Типичный инцидент на Level 2:

• 02:00 - Сервер упал

• 02:00:05 - Автоматический alert поступил на на-call инженера

• 02:01 - Система автоматически запустила recovery процесс

• 02:02 - Сервис восстановился автоматически

• 02:05 - On-call инженер получил alert, проверил, что всё OK

• 02:10 - Инженер пошёл спать

• 08:00 - Инженер просматривает логи, понимает, что произошло

• Итого: 2 минуты downtime, один человек потерял 5 минут сна

6. IT начинает понимать бизнес

На Level 1 IT и бизнес говорили на разных языках.

На Level 2 они начинают синхронизироваться.

Как это выглядит:

Level 1 диалог:

• Бизнес: "Нам нужна новая CRM"

• IT: "OK, это будет Salesforce, 50 млн ₽, 6 месяцев"

• Бизнес: "Это дорого. Может быть, бесплатный инструмент?"

• IT: "Бесплатный инструмент некачественный"

• (конец диалога, ничего не решено)

Level 2 диалог:

• Бизнес: "Нам нужна новая CRM. Почему? Потому что текущая система медленная, и мы теряем 10% leads"

• IT: "Понял. Потеря 10% leads = потеря какого-то объёма выручки? Сколько?"

• Бизнес: "Примерно 5 млн ₽ в год"

• IT: "OK, тогда ROI от новой CRM = экономия 5 млн ₽ в год. Если CRM стоит 50 млн ₽, то окупится за 10 лет?"

• Бизнес: "Нет, нам нужно, чтобы окупилась за 2 года"

• IT: "Тогда нужно сэкономить 25 млн ₽ в год. Новая CRM сама по себе даст только 5 млн. Нам нужны другие улучшения. Например, автоматизация процесса продаж даст ещё 15 млн, интеграция с маркетингом даст ещё 5 млн"

• Бизнес: "OK, давайте так"

• IT: "Тогда план такой: месяц на требования и дизайн, 2 месяца на разработку автоматизации, 1 месяц на интеграцию, 1 месяц на тестирование и обучение. Итого 5 месяцев. Стоимость: 30 млн ₽. ROI: 25 млн в год = окупится за 1.5 года"

• Бизнес: "Отлично, давайте начинать"

Результат: IT и бизнес согласованы. Они говорят на одном языке и понимают друг друга.

Финансовый эффект Level 2

Значительная экономия от улучшений

До Level 2 (на Level 1):

• Downtime: 3% в год = ~30 млн ₽ потерь (для компании с 1 млрд выручки)

• Ошибки в production: 10% бюджета IT уходит на фиксинг = 10 млн ₽

• Срывы проектов: бизнес не получает фичи вовремя, потери от отложенного revenue = 50 млн ₽

• Итого потери: ~90 млн ₽ в год

После Level 2:

• Downtime: 1% в год = ~10 млн ₽ потерь

• Ошибки в production: 3% бюджета IT = 3 млн ₽

• Срывы проектов: большинство проектов в срок, потери = 10 млн ₽

• Итого потери: ~23 млн ₽ в год

Экономия: 67 млн ₽ в год!

Даже если компания инвестирует 20 млн ₽ в улучшения IT (hiring, tooling, automation), ROI все равно 335% за первый год.

Люди счастливее и не выгорают

На Level 1 люди работают по ночам несколько раз в месяц из-за emergency.

На Level 2 люди работают по ночам несколько раз в год (или не работают вообще).

Результат:

• Меньше текучки (люди не уходят из-за выгорания)

• Больше производительности (отдохнувшие люди работают лучше)

• Лучший найм (люди хотят работать в компании, где не нужно работать по ночам)

IT может быть Strategic Partner

На Level 1 IT — это Cost Center. Бизнес смотрит на IT как на необходимое зло.

На Level 2 IT становится Strategic Partner. Бизнес советуется с IT о стратегических решениях.

Пример:

• Бизнес хочет выйти на новый рынок

• Бизнес не говорит "IT, внедри новую систему"

• Бизнес говорит "IT, как ты видишь, с какой точки зрения технологии, как нам войти на этот рынок?"

• IT помогает с анализом, рекомендациями, оценкой рисков

Результат: IT влияет на стратегию, не просто выполняет приказы.

Типичные компании на Level 2

Зрелые компании (500+ человек, 10+ лет на рынке)

• Были на Level 1, постепенно внедрили процессы

• Наняли CTO/IT-директора, который верит в процессы

• Потратили год-два на automatизацию и улучшения

Tech-компании (которые считают IT важным)

• Яндекс, Сбер, Тинькофф — все на Level 2+ для критичных систем

• Google, Amazon, Facebook — давно прошли Level 2

Компании с регуляторными требованиями

• Банки (нужна документация всех процессов)

• Страховые компании (нужна надёжность)

• Компании обороны (нужна безопасность)

Симптомы Level 2

Процессы автоматизированы и следуются всегда

• Нельзя коммитить без code review

• Нельзя развернуть без автоматических тестов

• Нельзя мёржить без approvals

Метрики используются каждый день

• Есть dashboard с ключевыми метриками

• Люди знают, за какие метрики они отвечают

• Решения принимаются на основе данных

Планирование точное

• Большинство проектов заканчиваются в оценку (±20%)

• Если задержка, причина известна и задокументирована

IT и бизнес говорят на одном языке

• Когда бизнес описывает требование, IT понимает ROI

• Когда IT рекомендует решение, бизнес понимает, почему

Люди довольны

• Люди н�� работают по ночам регулярно

• People хвалят процессы, а не жалуются

• Текучка низкая

Downtime редкий

• Когда что-то сломается, система восстановится сама

• Люди узнают о проблеме за секунды, а не часы

Путь к Level 3

На Level 2 компания стабильна и предсказуема. Процессы работают, люди счастливы, бизнес получает результаты.

Но есть проблема: Level 2 требует много ручного управления.

• Нужно вручную запускать release checklist

• Нужно вручную решать, какие фичи в какой release

• Нужно вручную координировать развёртывание между командами

• Нужно вручную анализировать метрики и принимать решения

На Level 3 большая часть этого автоматизируется.

Вместо "каждую неделю вручную выпускаем release", система выпускает несколько релизов в день автоматически.

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

Level 3 — когда процессы становятся автоматизированными, и люди занимаются только стратегией и инновациями.

Введение

На Level 0-1 процессы были документированы, но люди их нарушали. На Level 2 процессы были автоматизированы, и люди их соблюдали всегда.

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

Level 3 — это точка, где компания перестаёт быть "IT, которая поддерживает бизнес" и становится "IT, которая ускоряет и трансформирует бизнес".

Что такое Level 3?

Level 3 — это состояние, когда:

• Процессы определены, документированы и постоянно оптимизируются

• Continuous Improvement культура встроена в ДНК организации

• Автоматизация захватывает 60-70% операций

• Время вывода новых фич сократилось до недель, а не месяцев

• Проакция (предотвращение проблем) вместо реакции (решение проблем после их возникновения)

• IT и бизнес полностью синхронизированы и работают как одна команда

На Level 3:

• Continuous Integration/Deployment (CI/CD) — фичи выходят в production несколько раз в день

• Метрики и анализ — каждое решение основано на данных, есть A/B тестирование

• Infrastructure as Code — вся инфраструктура описана в коде, версионируется, как обычный код

• DevOps culture — разработчики и операции работают как одна команда

• Post-mortems вместо blame — когда что-то ломается, не ищут виноватого, а ищут, что можно улучшить в системе

Ключевые характеристики Level 3

1. Continuous Integration и Continuous Deployment (CI/CD)

На Level 2 было:

• Разработчик пишет код, коммитит

• CI pipeline запускает тесты

• Если тесты прошли, код готов к deployment

• Но deployment делается вручную, по расписанию (например, раз в неделю в пятницу)

На Level 3:

• Разработчик пишет код, коммитит

• CI pipeline запускает тесты (unit, integration, e2e)

• Если тесты прошли, код автоматически деплоится в production

• Это происходит несколько раз в день

Как это работает:

1. Development: разработчик работает в своей ветке

2. Commit: коммит с описанием изменений

3. Trigger CI/CD: GitHub/GitLab видит коммит, автоматически запускает pipeline

4. Automated tests: система запускает все тесты (15-20 минут)

5. Build: если тесты прошли, система собирает приложение (Docker image)

6. Deploy to staging: приложение развёртывается на staging окружении

7. Smoke tests: система прогоняет critical тесты на staging

8. Deploy to production: если всё OK, приложение автоматически деплоится в production

9. Health checks: система проверяет, что приложение работает в production

10. Rollback (if needed): если что-то пошло не так, система автоматически откатывается на предыдущую версию

Всё это происходит в 20-30 минут, без участия человека.

Результат:

• На Level 2: 1-2 deployment в неделю

• На Level 3: 20-50+ deployments в день

• Бизнес может выпустить фичу в production за часы или дни, а не за месяцы

Пример из реальной жизни:

Netflix имеет 200+ microservices. Каждый сервис может деплоиться независимо. В результате:

• Netflix делает 200+ deployments в день

• Каждый deploy занимает 15-20 минут

• Если что-то ломается, откатываются за 30 секунд

• Это позволяет Netflix быстро реагировать на спрос пользователей

2. Infrastructure as Code (IaC)

На Level 2 инфраструктура была создана "вручную":

• DevOps инженер SSH-ится на сервер

• Вручную устанавливает софт

• Вручную конфигурирует сетевые настройки

• Вручную создаёт базы данных

На Level 3 инфраструктура описана в коде:

• Все конфигурации в файлах (Terraform, Ansible, Docker Compose и т.д.)

• Эти файлы версионируются в Git

• Разработчик может создать новое окружение (development, staging, production) одной командой: terraform apply

Пример:

text# terraform/main.tf
resource "aws_ec2_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
  
  tags = {
    Name = "Production Web Server"
  }
}

resource "aws_rds_instance" "database" {
  allocated_storage    = 20
  engine              = "postgres"
  engine_version      = "13.7"
  instance_class      = "db.t2.micro"
  
  tags = {
    Name = "Production Database"
  }
}

# terraform/main.tf resource "aws_ec2_instance" "web_server" { ami = "ami-0c55b159cbfafe1f0" instance_type = "t2.micro" tags = { Name = "Production Web Server" } } resource "aws_rds_instance" "database" { allocated_storage = 20 engine = "postgres" engine_version = "13.7" instance_class = "db.t2.micro" tags = { Name = "Production Database" } }

Когда разработчик нужна новая окружение:

bashterraform plan    # посмотреть, что создастся
terraform apply   # создать инфраструктуру

terraform plan # посмотреть, что создастся terraform apply # создать инфраструктуру

Результат:

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

• Инфраструктура документируется (код — это документация)

• Инфраструктуру можно создать/удалить за минуты

• Disaster recovery проще (если сервер упал, создаём новый за минуты)

3. Культура Continuous Improvement

На Level 2 улучшения были плановыми:

• Один раз в месяц встреча "что улучшить?"

• Обсуждают метрики

• Выбирают 1-2 улучшения

• Внедряют в течение месяца

На Level 3 улучшения постоянные:

• После каждого спринта (1-2 недели) — ретроспектива

• Каждый день — small improvements

• Каждую неделю — анализ метрик

• Каждый месяц — big improvements

Как это работает:

Daily standup (15 минут):

• Что сделали вчера?

• Что делаем сегодня?

• Что мешает?

Если что-то мешает, это решается сегодня же, не откладывается.

Sprint retrospective (1 час, каждые 2 недели):

• Что хорошо прошло?

• Что плохо прошло?

• Что будем делать по-другому?

Weekly metrics review (30 минут):

• Deployment frequency: как часто деплоим?

• Lead time: сколько времени от коммита до production?

• Mean time to recovery (MTTR): если упал сервис, сколько времени восстанавливаем?

• Change failure rate: какой % deployments приводит к проблемам?

На основе этих метрик принимаются решения:

• "MTTR высокий (2 часа), нужно улучшить мониторинг"

• "Change failure rate 10%, нужно больше автоматических тестов"

• "Lead time 2 недели, можно ли сократить до 1 недели?"

Результат:

• Процессы улучшаются постоянно, а не раз в месяц

• Каждый день система становится немного лучше

• За год компания становится в 2-3 раза лучше, чем была

4. DevOps культура — разработка и операции как одна команда

На Level 1-2 было разделение:

• Developers: "Это работает на моём ноутбуке!"

• Operations: "Но в production не работает!"

На Level 3 нет разделения:

• Разработчик пишет код

• Тот же разработчик следит, как это работает в production

• Если что-то сломалось, тот же разработчик это чинит

Как это организуется:

1. On-call rotation: каждую неделю один разработчик — on-call (если что-то сломается, ему звонят/пишут)

2. Ownership: разработчик "владеет" своим сервисом — от разработки до production

3. Blameless post-mortems: если что-то сломалось, не ищут виноватого, а ищут, что можно улучшить в системе

Пример blameless post-mortem:

Сценарий:

• В 3 часа ночи упала payment система

• On-call разработчик не заметил (мониторинг плохой)

• Downtime 2 часа

• Потери: 5 млн ₽

Level 2 post-mortem:

• "Кто развернул это? Почему ты не протестировал?"

• Разработчик: "Я тестировал, просто не заметил этот сценарий"

• Вывод: "Нужно быть осторожнее"

• (Ничего не меняется)

Level 3 post-mortem:

• "Что произошло?" — На payment систему была приложена нагрузка, одна база данных упала, система не смогла failover на другую БД

• "Почему это не было поймано?" — Мониторинг не отправил alert

• "Почему мониторинг не отправил alert?" — Alert был, но on-call разработчик спал, и на его телефоне звук был выключен

• "Почему звука не было?" — Потому что он знал, что alert часто срабатывает ложно, и он отключил звук

• "Почему alert срабатывает ложно?" — Потому что настроен на слишком низкий порог

Выводы и действия:

1. Улучшить настройку alert, чтобы было меньше ложных срабатываний

2. Улучшить redundancy БД, чтобы failover работал автоматически

3. Улучшить систему уведомления, чтобы оно было гарантировано доставлено (SMS + email + push notification)

4. Добавить на-call инженера для очень критичных сервисов

Результат:

• Вместо "обвинили разработчика", улучшили систему

• Следующий раз, если что-то упадет, система восстановится сама, и нужно будет меньше ручной работы

5. A/B тестирование и data-driven decisions

На Level 2 метрики собирались, но использовались редко.

На Level 3 каждое изменение тестируется через A/B тесты.

Пример:

Netflix хочет изменить интерфейс рекомендаций:

• Вариант A (текущий): рекомендации показываются в горизонтальном скролле

• Вариант B (новый): рекомендации показываются в карточках

Netflix не просто выпускает вариант B для всех. Netflix:

1. Выбирает 5% пользователей случайно

2. Показывает им вариант B, остальным — вариант A

3. Собирает метрики:

   • Какой % пользователей кликнул на рекомендацию?

   • Сколько времени они смотрели видео?

   • Сколько видео они посмотрели?

   • Остались ли они подписчиками?

4. Через неделю анализирует результаты:

   • Вариант B: +5% кликов, +10% времени просмотра

   • Это статистически значимо (95% confidence)

5. Расширяет тест на 20% пользователей, потом 50%, потом всех

Результат:

• Netflix делает решения на основе реальных данных, а не гаданий

• Netflix может добавить +0.5% конверсии, что равно 50 млн долларов в год (для их размера)

6. Проактивный мониторинг вместо реактивного

На Level 1-2:

• Что-то упало

• Alert поступил

• Инженер проснулся и чинил

На Level 3:

• Система видит, что что-то идёт не так, ещё до того, как упадёт

• Система автоматически пытается исправить

• Если не смогла исправить, уведомляет инженера

• Инженер может исправить спокойно, днём, а не ночью

Пример:

Сервер близко к памяти:

• Level 1-2: сервер закончит память, упадет, alert поступит ночью

• Level 3: система видит, что памяти осталось 20%, автоматически:

  • Чистит кэш

  • Перенаправляет трафик на другие серверы

  • Отправляет инженеру: "Привет, была проблема с памятью, я её исправил. Рекомендую добавить ещё 10GB памяти на этот сервер"

Результат:

• Uptime: 99.9%+ (вместо 98% на Level 2)

• Люди не просыпаются ночью (вместо нескольких раз в месяц на Level 2)

7. Быстрая обратная связь (Feedback loops)

На Level 2:

• Разработчик пишет код

• Коммитит

• Тесты прогоняются (15-20 минут)

• Разработчик смотрит результат

Это называется "feedback cycle of 20 minutes" — разработчик получает результат своего кода за 20 минут.

На Level 3:

• Feedback cycle 5 минут или меньше

Как? Потому что:

• Раннее тестирование: тесты прогоняются локально на ноутбуке, до коммита

• Быстрые тесты: unit тесты занимают 1-2 минуты (не 10-15)

• Параллельное выполнение: тесты выполняются на нескольких машинах одновременно

Результат:

• Разработчик сразу видит, работает ли его код

• Разработчик может исправить ошибку в тот же момент, пока помнит, что писал

• Производительность разработчика выше на 20-30%

Финансовый эффект Level 3

Скорость — главное конкурентное преимущество

На Level 2:

• Новая фича от идеи до production: 2-3 месяца

• За год компания выпускает 4-6 больших фич

На Level 3:

• Новая фича от идеи до production: 2-3 недели

• За год компания выпускает 20-30 больших фич

Бизнес-результат:

• Конкурент выпустил новую фичу? Level 3 компания может выпустить аналог за неделю

• Рынок изменился? Level 3 компания может адаптироваться за дни

• Клиент попросил новую фичу? Level 3 компания может её дать за неделю

Финансовый эффект:

• Market share: Level 3 компания держит 2x больше market share, чем Level 2 конкурент

• Revenue: если Level 3 компания растить на 30% в год, Level 2 растит на 10%

• За 5 лет: Level 3 компания становится в 3-4x больше, чем Level 2

Стабильность и надёжность

На Level 2:

• Downtime: 1-2% в год = ~4 млн ₽ потерь для компании с 1 млрд выручки

• Ошибки в production: случаются еженедельно

На Level 3:

• Downtime: 0.1-0.5% в год = ~400K ₽ потерь

• Ошибки в production: случаются раз в месяц

Экономия от надёжности:

• 3-4 млн ₽ в год от отсутствия downtime

• 2-3 млн ₽ в год от отсутствия emergency fixes и overtime

Качество кода

На Level 3 quality кода выше, потому что:

• Автоматические тесты покрывают 80%+ кода

• Code review более строгие (потому что система не позволит мёржить без review)

• Continuous improvement культура значит, что люди постоянно учатся

Результат:

• Technical debt низкий (код чистый, быстрый, легко поддерживать)

• Разработчики могут добавить фичу быстрее (потому что код чистый, а не грязный)

• Ошибки реже (потому что тесты покрывают много)

ROI от инвестиций в IT

Инвестиция: 50 млн ₽ в год на разработку и операции.

Level 2 результаты:

• 10% потеря на downtime и ошибках = 5 млн ₽ потерь

• 60% разработки идёт на новые фичи = 30 млн ₽ на новые фичи

• ROI: 30 млн новых фич / 50 млн инвестиции = 60% ROI

Level 3 результаты:

• 2% потеря на downtime и ошибках = 1 млн ₽ потерь

• 75% разработки идёт на новые фичи = 37.5 млн ₽ на новые фичи

• ROI: 37.5 млн новых фич / 50 млн инвестиции = 75% ROI

Плюс, Level 3 позволяет быстрее выводить фичи, что даёт дополнительный revenue от новых фич.

Типичные компании на Level 3

Tech-гиганты:

• Netflix: CI/CD, chaos engineering, microservices

• Amazon: everything as code, автоматизированное развёртывание

• Google: internal tools, automated optimization

• Яндекс: continuous deployment, A/B тестирование на всё

Крупные tech-компании:

• Facebook: continuous deployment (несколько deployments в день)

• Spotify: autonomous squads, continuous deployment

• Uber: microservices, continuous deployment

Российские компании:

• Яндекс: достигла Level 3 лет 10 назад

• Сбер: частично на Level 3 для критичных систем

• Тинькофф: построена на Level 3 с самого начала

Симптомы Level 3

Deployment frequent and routine

• Deployments несколько раз в день — это НОРМА

• Люди не нервничают перед deployment, это обычное дело

Metrics everywhere

• Каждый инженер знает 3-5 главных метрик, за которые он отвечает

• Решения принимаются на основе данных, а не гаданий

Blameless culture

• Когда что-то ломается, не ищут виноватого

• Ищут, что можно улучшить в системе

Automation-first mindset

• Если что-то требует ручной работы 2+ раза, автоматизируют

• Infrastructure as code, all the way

Proactive не reactive

• Проблемы предотвращаются, а не решаются после возникновения

• Мониторинг и алерты настроены так, чтобы видеть проблемы заранее

Innovation time

• 20-30% времени инженеры тратят на эксперименты и улучшения

• Новые идеи быстро тестируются через A/B тесты

Low turnover

• Люди остаются в компании (средний стаж 4-5 лет)

• Это значит, что люди довольны и видят смысл в своей работе

Путь к Level 4

На Level 3 компания очень хороша в выполнении существующих процессов. Процессы оптимизированы, автоматизированы, люди счастливы.

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

На Level 4 система становится проактивной и самооптимизирующейся:

• Machine Learning модели предсказывают, что пойдет не так, до того как это произойдет

• Система сама находит оптимальное решение и внедряет его

• Люди занимаются только стратегией и созданием новых продуктов

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

УРОВЕНЬ 4 ЗРЕЛОСТИ IT: MANAGED AND OPTIMIZED

Введение

На Level 0-2 компания боролась за выживание. На Level 3 компания научилась хорошо работать, процессы оптимизировались постоянно.

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

Вместо этого, система сама себя оптимизирует. Machine Learning находит узкие места. Автоматизация внедряет улучшения. Люди занимаются только стратегией и инновациями.

Level 4 — это точка, где IT перестаёт быть функцией и становится стратегическим активом, который создаёт конкурентное преимущество.

Что такое Level 4?

Level 4 — это состояние, когда:

• Все процессы управляемы и оптимизируемы

• Machine Learning и AI используются для автоматизации решений

• Прогнозируемость ±5-10% (вместо ±20% на Level 3)

• Точность оценок проектов основана на моделях ML

• Система сама себя оптимизирует (без участия человека)

• 70-80% операций автоматизировано (вместо 60% на Level 3)

• IT полностью синхронизирована с бизнесом и думает как CEO

На Level 4:

• Predictive maintenance: система знает, какой сервер упадёт завтра, и заменяет его сегодня

• Automated optimization: система сама находит узкие места и оптимизирует код

• Self-healing infrastructure: когда что-то ломается, система автоматически восстанавливается без участия человека

• Intelligent monitoring: система знает, что нормально, а что нет (не нужны ручные пороги для алертов)

• Autonomous decision making: система принимает решения о развёртывании, scaling, и оптимизации без подтверждения человека

Ключевые характеристики Level 4

1. Machine Learning для прогнозирования и оптимизации

На Level 3 метрики собирались и анализировались людьми.

На Level 4 ML модели собирают метрики и автоматически находят улучшения.

Пример 1: Предсказание времени проекта

Level 3:

• Разработчик оценивает проект: "Это займет 3 недели"

• На основе историчских данных: средний проект из 5 story points занимает 3 недели

• Оценка: 3 недели (±20%, т.е. 2.4-3.6 недели)

Level 4:

• Система видит новый проект

• Система анализирует:

  • Похожие проекты в истории

  • Характеристики: технологии, размер, сложность, команда

  • Сезонность: новые разработчики медленнее, в летние месяцы меньше focus

  • Риски: зависит ли это от других проектов?

• ML модель предсказывает: "Этот проект займет 18.5 дней (±3%)"

• Оценка: 18.5 дней (±3%, т.е. 17.95-19.05 дней)

Точность: Level 4 точнее в 6.7 раза!

Как это работает:

1. Компания собирает исторические данные за 5+ лет: 1000+ проектов

2. Для каждого проекта: duration, team size, technologies, complexity, dependencies

3. ML модель (например, XGBoost) обучается на этих данных

4. Модель находит паттерны: "Проекты с React и Node.js обычно быстрее", "Новые разработчики медленнее на 30%"

5. Когда приходит новый проект, модель говорит точную оценку

Пример 2: Оптимизация производительности кода

Level 3:

• Разработчик профилирует код вручную: "Какие функции медленные?"

• Находит узкие места вручную

• Оптимизирует вручную

Level 4:

• Система непрерывно профилирует код в production

• ML модель анализирует метрики профилирования

• Система видит: "Функция X работает медленнее, чем год назад. Почему?"

• Система анализирует:

  • Объём данных увеличился в 2 раза

  • Алгоритм имеет O(n²) сложность

  • При n=1M это даёт 10M операций, вместо 1M год назад

• Система предлагает: "Нужно переписать алгоритм на O(n log n)"

• Система даже может автоматически написать оптимизированный код (если используется AI кодирование)

• Результат: производительность улучшена на 100x, пользователи не заметили

Пример 3: Оптимизация инфраструктуры

Level 3:

• DevOps смотрит на метрики: "CPU использование 80%, нужно добавить ещё сервер?"

• Решение принимает человек

Level 4:

• Система видит паттерн: "Каждый понедельник в 10:00 CPU скачет до 90%, потом падает"

• Система предсказывает: "В следующий понедельник в 10:00 будет пик"

• Система автоматически:

  • Запускает дополнительный сервер в 09:55

  • Распределяет трафик

  • В 11:00 отключает дополнительный сервер

• Результат: нет downtime, нет ручного вмешательства

2. Predictive maintenance (предиктивное обслуживание)

На Level 3 инциденты случаются, потом их чинят.

На Level 4 система предсказывает, когда что-то упадёт, и предотвращает это.

Как это работает:

Сценарий: Hard drive может скоро упасть

Level 3:

• Система собирает SMART метрики (температура, количество ошибок, возраст)

• Когда drive выходит из строя, система видит "CRITICAL ERROR, drive failed"

• Data center посылает инженера заменить drive

• 1-2 часа downtime

Level 4:

• Система непрерывно собирает SMART метрики

• ML модель анализирует метрики 1000+ drives

• Модель знает: "Если error rate растёт, а возраст drive > 5 лет, drive упадёт в течение недели с 95% вероятностью"

• Система предвидит: "Drive на сервере X-123 упадёт в течение 3-5 дней"

• Система автоматически:

  1. Начинает миграцию данных на другие drives

  2. Заказывает replacement drive

  3. Отправляет на-call инженеру: "Привет, у тебя есть 3 дня заменить drive на сервере X-123, я уже мигрировал данные"

• Инженер спокойно заменяет drive днём, а не ночью

• Downtime: 0 минут (данные уже перемещены)

Результат: никаких экстренных звонков в 3 часа ночи.

3. Autonomous decision making в development

На Level 3 люди принимают решения: "Нужно ли деплоить этот код?"

На Level 4 система сама принимает решения.

Пример: Autonomous deployment

Level 3:

• Разработчик пушит код

• CI/CD pipeline проходит все тесты

• Код деплоится в production автоматически

• Если что-то ломается, система откатывается вручную (или автоматически, если настроили)

Level 4:

• Разработчик пушит код

• CI/CD pipeline проходит все тесты

• Система анализирует:

  • Риск этого изменения? Низкий (изменили CSS, не логику)

  • История подобных изменений? 99% успеха

  • Текущее состояние production? Stable, CPU < 50%, RAM < 60%

  • Есть ли better time для deployment? Да, сейчас 2 часа ночи, лучше в 10 часов утра

• Система принимает решение: "Деплоим в 10 часов утра"

• В 10 часов утра:

  • Система деплоит код на 10% трафика (canary deployment)

  • Система мониторит метрики: error rate, latency, CPU

  • Если всё OK после 5 минут, деплоит на 50% трафика

  • Если всё OK после 5 минут, деплоит на 100% трафика

  • Если что-то пошло не так, откатывает автоматически

• Результат: deployment прошел успешно, без участия человека

Другой пример: Autonomous scaling

Level 3:

• Traffic растёт

• CPU использование 80%

• Alert отправляется на-call инженеру

• Инженер просыпается, смотрит метрики, добавляет сервер

• 30 минут downtime или degraded performance

Level 4:

• Traffic растёт

• ML модель видит: "Traffic растёт по паттерну, который мы видели в прошлые вторники. Через 5 минут будет пик."

• Система автоматически:

  • Запускает дополнительные инстансы (автоматизированно через Kubernetes)

  • Распределяет трафик через load balancer

  • Мониторит метрики

• Traffic пик происходит, но system справляется (CPU 60%)

• Через час, когда traffic падает, система отключает дополнительные инстансы

• Результат: zero downtime, zero manual intervention

4. Intelligent monitoring без ручных порогов

На Level 3 мониторинг требует ручной настройки порогов:

• Alert если CPU > 80%

• Alert если memory > 85%

• Alert если latency > 500ms

Проблема: пороги зависят от контекста. CPU 80% в 3 часа ночи — это нормально. CPU 80% в 10 часов утра — это плохо.

На Level 4 ML модель сама определяет, что нормально, а что нет.

Как это работает:

Anomaly detection:

1. Система собирает метрики за 3-6 месяцев

2. ML модель (например, Isolation Forest или Autoencoders) учится на нормальных данных

3. Модель создает "профиль нормального поведения":

   • В понедельник утром CPU обычно 45-60%

   • В понедельник вечером CPU обычно 30-40%

   • В пятницу перед выпуском CPU может быть 70-85%

4. Когда новые данные приходят, модель сравнивает:

   • Ожидаемый CPU для понедельника утра: 45-60%

   • Фактический CPU: 92%

   • Это anomaly! Alert отправляется

Преимущества:

• Не нужно ручно подбирать пороги

• Модель адаптируется: летом может быть меньше пользователей, модель это знает

• Модель учится: после третьего deploy в день, модель знает, что это нормально

Результат: на 70% меньше ложных алертов, но все настоящие проблемы ловятся.

5. Полная синхронизация IT и бизнеса

На Level 3 IT и бизнес работают в синхронии.

На Level 4 IT и бизнес — это одна команда.

Как это выглядит:

Level 3 диалог:

• Бизнес: "Нам нужна функция X, это принесёт 10 млн ₽ в год"

• IT: "Это займет 2 месяца, стоит 5 млн ₽"

• Бизнес: "OK, давайте начинать"

Level 4 диалог:

• Бизнес: "Нам нужна функция X"

• IT: "Погодите, давайте первый проверим через A/B тест. Сделаем MVP за 1 неделю (500K ₽), покажем 5% пользователей, измерим ROI"

• Бизнес: "Отлично"

• Через неделю:

• IT: "MVP готов, 5% пользователей видят функцию X. Метрики:"

  • Конверсия выросла на 2% (лучше, чем ожидали 1%)

  • Average order value выросла на 5% (неожиданный результат!)

  • Customer retention улучшилась на 0.5%

• Бизнес: "Это даст нам 20 млн ₽, а не 10 млн"

• IT: "Отлично, тогда давайте выкатим на 100% пользователей. Это займет 1 неделю (500K ₽)"

• Через неделю функция X на 100% пользователей

Ключевое различие:

• Level 3: "Давайте сделаем функцию X"

• Level 4: "Давайте сначала проверим гипотезу, потом решим, нужна ли функция X"

Результат:

• 50% функций, которые казались хорошей идеей, оказываются плохой идеей

• Компания экономит миллионы на разработку функций, которые никому не нужны

• Компания внедряет только функции, которые приносят реальный ROI

6. 70-80% операций автоматизировано

На Level 3 60% операций автоматизировано.

На Level 4 70-80% автоматизировано.

Это означает:

• Развёртывание: автоматическое (вместо 50% автоматизации на Level 3)

• Scaling: автоматическое

• Мониторинг: автоматическое

• Backup и recovery: автоматическое

• Security patches: автоматическое (включая перезагрузку сервера)

• Optimization: автоматическое

• Alerting: автоматическое (с ML, без ручных порогов)

Результат:

• On-call инженер спит всю ночь (система сама всё чинит)

• DevOps занимается только стратегией и архитектурой, не операциями

7. Непрерывное обучение и адаптация

На Level 3 система работает хорошо, но статична.

На Level 4 система постоянно учится.

Как это работает:

ML model retraining:

• Каждый день система переучивает ML модели на новых данных

• Модели становятся точнее с каждым днём

• Например, модель предсказания времени проекта через год точнее, чем в начале

Feedback loops:

• Когда что-то предсказала модель, система отслеживает, правильно ли предсказала

• Если модель ошиблась на 30%, система отмечает это

• Если много ошибок, модель переучивается с другими параметрами

Autonomous optimization:

• Система не просто выполняет оптимизации, она измеряет эффект

• Если оптимизация не дала ожидаемого результата, система отменяет её

• Это называется "canary optimization" (похоже на canary deployment)

Результат:

• Через месяц система лучше, чем была

• Через год система на 3-5x лучше, чем год назад

Финансовый эффект Level 4

Скорость разработки — 10x improvement

Level 3:

• Новая фича от идеи до production: 2-3 недели

• За год: 20-30 фич

Level 4:

• Новая фича от идеи до production: 3-5 дней

• Фичи выходят в production десятки раз в день

• За год: 200-300 фич (или даже больше)

Бизнес-результат:

• Компания в 10x быстрее реагирует на рынок

• Компания может попробовать 10 идей за время, за которое конкурент пробует 1

• 90% идей окажутся плохими, но 10% окажутся золотыми

• За год компания находит несколько новых источников revenue, каждый стоит по 100+ млн ₽

Надёжность и стабильность — премиум класс

Level 3:

• Uptime: 99.9% (4 часа downtime в год)

Level 4:

• Uptime: 99.95%+ (2-3 часа downtime в год)

• Для критичных функций: 99.99%+ (30 минут downtime в год)

Бизнес-результат:

• Клиенты видят, что сервис на 99.99% надёжен

• Клиенты готовы платить больше (SLA контракты с премиум ценой)

• Клиенты не переходят к конкурентам (потому что тот менее надёжен)

Операционная эффективность

Level 3:

• 10 DevOps инженеров управляют инфраструктурой для 500 разработчиков

• Ratio: 1 DevOps на 50 разработчиков

Level 4:

• 5 DevOps инженеров управляют инфраструктурой для 500 разработчиков

• Ratio: 1 DevOps на 100 разработчиков

• Оставшиеся 5 DevOps инженеров занимаются стратегией и новыми проектами

Финансовый эффект:

• Зарплата DevOps инженера: 300K ₽/месяц

• Экономия: 5 × 300K × 12 = 18 млн ₽ в год

• Плюс, эти 5 инженеров работают на новые проекты, которые приносят дополнительный revenue

ROI от IT инвестиций

Инвестиция: 100 млн ₽ в год на разработку и операции (для крупной компании).

Level 3 результаты:

• 2% потеря на downtime и ошибках = 2 млн ₽ потерь

• 75% разработки идёт на новые фичи = 75 млн ₽ на новые фичи

• Плюс, экономия на операциях = 5 млн ₽

• Итого benefit: 78 млн ₽

• ROI: 78% (каждый рубль инвестиции даёт 0.78 ₽ прибыли)

Level 4 результаты:

• 0.5% потеря на downtime и ошибках = 0.5 млн ₽ потерь (экономия 1.5 млн vs Level 3)

• 85% разработки идёт на новые фичи = 85 млн ₽ на новые фичи

• Плюс, экономия на операциях = 10 млн ₽

• Плюс, благодаря A/B тестированию, качество фич выше, ROI от фич = 150% вместо 100%

  • 85 млн ₽ × 150% = 127.5 млн ₽ (вместо 85 млн)

• Итого benefit: 138 млн ₽

• ROI: 138% (каждый рубль инвестиции даёт 1.38 ₽ прибыли)

Плюс, Level 4 позволяет разработчикам и IT лидерам заниматься стратегией, что может привести к новым бизнес-идеям и источникам revenue.

Типичные компании на Level 4

Tech-гиганты:

• Amazon: autonomous scaling, predictive maintenance, everything as code

• Netflix: chaos engineering, autonomous decisions, ML for optimization

• Google: ML for everything, autonomous optimization, predictive failures

• Meta (Facebook): continuous deployment, autonomous decisions, ML for performance

Large-scale tech companies:

• Uber: real-time optimization, autonomous scaling, ML for demand prediction

• Airbnb: continuous deployment, ML for personalization, autonomous optimization

• Spotify: autonomous decisions, ML for recommendations

Российские компании:

• Яндекс: достигла Level 4 несколько лет назад

• Сбер: Level 4 для критичных систем

• Avito: Level 4 для core systems

Симптомы Level 4

Deployments are boring

• Deployments happening 10-50+ times a day is normal

• Nobody gets nervous about deployments

• Failures are rare and automatically recovered

Metrics everywhere, but no human analysis

• ML models continuously analyze metrics

• Models predict problems before they happen

• Models recommend solutions

Autonomous systems

• Infrastructure scales itself

• Deployments happen automatically

• Optimizations happen automatically

• People approve decisions, not make them

Experimentation culture

• A/B testing on everything

• New ideas tested quickly (days, not weeks)

• Failed experiments don't cost much

• Successful experiments scale quickly

Team efficiency

• Same team size but 10x more features shipped

• People are not tired (no on-call emergencies)

• People focus on strategy, not firefighting

Predictive, not reactive

• Problems are prevented before they happen

• Monitoring is intelligent (ML-based)

• Recovery is automatic

Путь к Level 5

На Level 4 компания очень хороша в управлении существующих систем и процессов.

Но есть вопрос: кто определяет стратегию? Люди.

На Level 5 даже стратегия становится data-driven и частично автоматизированной:

• ML модели предлагают, какие новые бизнес-направления развивать

• System самостоятельно экспериментирует с новыми продуктами

• People только одобряют больших стратегических решения, все тактические решения автоматизированы

Level 5 — когда система сама создаёт стратегию, находит новые рынки, и люди только одобряют.

УРОВЕНЬ 5 ЗРЕЛОСТИ IT: OPTIMIZING & INNOVATING

Введение

На Level 0 была хаос. На Level 1-2 появились процессы. На Level 3 процессы оптимизировались. На Level 4 система стала автоматизироваться.

На Level 5 происходит финальная трансформация. Система перестаёт быть просто "хорошо работающей машиной" и становится самосознающей, саморазвивающейся организацией.

На Level 5 IT не подчинена бизнесу. IT И ЕСТЬ бизнес. Система сама ищет новые рынки, сама экспериментирует, сама находит источники revenue.

Люди на Level 5 не управляют IT. Люди думают о будущем, пока система управляет настоящим.

Только 0.1% компаний в мире находятся на Level 5. Это Amazon, Google, Netflix, Facebook, Tesla. Это компании, которые не просто используют технологию, а создают её.

Что такое Level 5?

Level 5 — это состояние, когда:

• Система сама себя оптимизирует и инновирует (без участия человека)

• AI/ML модели принимают большинство решений (люди только одобряют)

• Инновация = культура на молекулярном уровне

• Люди тратят 60-70% времени на R&D и стратегию, остальное время на тактику

• Организация адаптируется к рынку быстрее, чем рынок меняется

• IT создаёт новые рынки и продукты, не просто поддерживает существующие

На Level 5:

• Self-optimizing systems: система анализирует себя и улучшает себя, люди только смотрят

• Autonomous innovation: система экспериментирует с новыми идеями, люди только одобряют

• Predictive strategy: система предсказывает, какие продукты будут успешны, люди утверждают

• Culture of experimentation: ошибка не штрафуется, это часть инновационного процесса

• Open innovation: компания публикует свои исследования, устанавливает стандарты индустрии

Ключевые характеристики Level 5

1. Self-optimizing systems — система улучшает саму себя

На Level 4 люди смотрели на метрики и утверждали улучшения.

На Level 5 система сама находит все возможные улучшения и внедряет их.

Как это работает:

Автоматическая оптимизация алгоритмов:

Представьте, что у вас есть система рекомендаций (как Netflix или Amazon).

Level 4:

• Data scientist смотрит на метрики: какой % пользователей нажимает на рекомендацию?

• Data scientist пробует 5 новых алгоритмов через A/B тесты

• Data scientist видит: алгоритм #3 лучше на 2%

• Data scientist внедряет алгоритм #3

Level 5:

• Система имеет 100 возможных алгоритмов рекомендаций

• Система автоматически тестирует все 100 алгоритмов параллельно (на разных % пользователей)

• Система отслеживает метрики: которые алгоритмы лучше, какие хуже, почему?

• Система видит: алгоритм #47 даёт +3% конверсии, но медленнее на 50ms. Нужно ли это trade-off?

• Система автоматически анализирует: если user ждёт на 50ms дольше, но конверсия +3%, это стоит?

  • Потеря от задержки: -0.5% конверсии

  • Прибыль от лучшего алгоритма: +3%

  • Net benefit: +2.5%

• Система внедряет алгоритм #47

• Система также экспериментирует с комбинациями алгоритмов:

  • Для одного типа пользователя использовать алгоритм #47

  • Для другого типа использовать алгоритм #23

  • Для третьего типа использовать алгоритм #91

• Система находит оптимальную комбинацию: +5% конверсии вместо +2% от одного алгоритма

Результат:

• Рекомендации на 5% лучше, чем были на Level 4

• Это вызывает +50 млн ₽ в год (для компании размером Netflix)

• Никто человек не работал над этим, система сама

Автоматическая оптимизация инфраструктуры:

Level 4:

• Infrastructure автоматически масштабируется на основе текущей нагрузки

• Если traffic растёт, добавляет сервера

Level 5:

• Система предсказывает future traffic за неделю, месяц

• Система предсказывает, где будут узкие места

• Система заранее оптимизирует архитектуру

• Например, система видит: "В следующем месяце video streaming traffic будет на 2x больше, текущая CDN архитектура не выдержит"

• Система автоматически:

  1. Добавляет новые CDN nodes в regions с высоким ожидаемым traffic

  2. Перетаскивает контент на новые nodes

  3. Переконфигурирует routing, чтобы использовать новые nodes

  4. Тестирует на staging

  5. Разворачивает в production

• Когда traffic действительно растёт, система готова

Результат:

• Никогда не бывает overload (потому что система заранее готовится)

• Latency остаётся низким (потому что архитектура оптимальна для предсказанной нагрузки)

2. Autonomous innovation — система экспериментирует с новыми идеями

На Level 4 люди придумывают идеи, и система их тестирует.

На Level 5 система сама генерирует идеи и тестирует их.

Как это работает:

Идея #1: Система анализирует customer data и генерирует новые фичи

Система видит:

• 30% пользователей никогда не смотрят фильмы в выходные

• Возможная гипотеза: может быть, они не знают, что смотреть?

• Идея: отправить им в пятницу email "5 фильмов, которые вы, вероятно, полюбите в выходные"

Level 4:

• Product manager видит эту гипотезу (или не видит)

• Product manager создаёт ticket в backlog

• Через 2 месяца team реализует фичу

• Фичу тестируют через A/B тест

Level 5:

• Система анализирует customer data

• Система генерирует 100+ гипотез о том, как увеличить engagement

• Система ранжирует гипотезы по predicted impact и effort:

  • Email гипотеза: effort = low, predicted impact = +2% engagement

  • Push notification гипотеза: effort = low, predicted impact = +3% engagement

  • Personalized homepage гипотеза: effort = high, predicted impact = +5% engagement

• Система автоматически реализует top-5 гипотез за week-end (в полностью автоматизированной pipeline)

• Система A/B тестирует их на 5% пользователей

• Через неделю система видит результаты и внедряет лучшие идеи на 100% пользователей

• Система также анализирует: почему некоторые идеи не сработали? И адаптирует генератор идей для будущего

Результат:

• +50 новых фич в месяц (вместо 5-10 на Level 4)

• Большинство не работают (как и ожидалось), но 10% работают отлично

• Эти 10% добавляют +200 млн ₽ в год revenue

Идея #2: Система ищет новые рынки

Система анализирует:

• Текущий бизнес: video streaming, генерирует 1 млрд ₽ в год

• Potential смежные рынки: music streaming? Gaming? Advertising?

Система может автоматически:

1. Test new markets: развернуть MVP music streaming сервиса за месяц (не 6 месяцев), покажет 5% пользователей

2. Collect data: как пользователи реагируют на music streaming? Какие метрики важны?

3. Predict success: на основе данных 5%, предсказать, будет ли это успешно на 100%?

4. Decide: если predicted success rate > 80%, внедрить на 100%. Если < 20%, отменить.

Результат:

• Компания находит 2-3 новых рынка в год

• Каждый новый рынок может быть стоит 100-500 млн ₽ в год

• Это делается автоматически, без участия product management или strategy teams

3. Predictive strategy — система предсказывает, что будет успешно

На Level 4 люди принимали стратегические решения.

На Level 5 система предсказывает результат стратегических решений.

Пример:

Компания обсуждает: "Нужно ли нам войти на рынок Бразилии?"

Level 4:

• Strategy team проводит анализ (2-3 месяца)

• Смотрит на population, GDP, internet penetration, конкуренцию

• Дает рекомендацию: "Да, это good opportunity, потенциальный market size 500 млн ₽"

• Компания выделяет бюджет и входит на рынок

• Через год видит: "О нет, мы заработали только 50 млн ₽, вместо 500 млн"

• Вывод: анализ был неправильным

Level 5:

• Система имеет данные о входе на рынки за последние 20 лет (100+ рынков)

• Система знает, какие факторы важны для успеха: population, GDP, internet penetration, местные конкуренты, культурные особенности и т.д.

• Система строит ML модель, которая предсказывает успех на основе этих факторов

• Система анализирует Бразилию:

  • Population: 215 млн (good)

  • GDP: 2 трлн ₽ (good)

  • Internet penetration: 65% (medium)

  • Существующие конкуренты: Netflix, Amazon Prime, local providers (есть конкуренция)

  • Cultural preference: португальский язык, другие предпочтения контента

• Система предсказывает: "Potential market size в Бразилии 300 млн ₽ (не 500), и нам нужно будет локализовать контент, что обойдется в 50 млн ₽. ROI = 2x за 3 года, это medium opportunity"

• Система также рекомендует: "Лучше закупить local provider за 50 млн ₽, чем создавать с нуля"

• Компания принимает решение на основе данных

Результат:

• Компания избегает ошибок, потому что знает, что ожидает

• Компания может решить: "Это не стоит риска", и избежать потери 100 млн ₽

4. Chaos engineering и resilience — система намеренно ломается для улучшения

На Level 4 была high reliability.

На Level 5 компания намеренно ломает систему, чтобы убедиться, что система может восстановиться.

Как это работает:

Netflix Chaos Monkey:

Netflix имеет инструмент "Chaos Monkey", который:

• Случайно выбирает сервер в production

• Отключает его (без предупреждения)

• Смотрит, что происходит

Зачем?

• Netflix хочет убедиться, что если сервер упадёт, система восстановится сама

• Если система НЕ восстановится, лучше это узнать в рабочее время, чем ночью

Пример:

• Chaos Monkey отключает сервер #123

• Система видит, что трафик не балансируется правильно

• Инженеры видят: "О, система не распределяет трафик, если сервер упал"

• Инженеры фиксят это в архитектуре

• Tomorrow, Chaos Monkey отключает другой сервер

• Система восстановилась сама, потому что архитектура была исправлена

Результат:

• Netflix имеет 99.99%+ uptime, потому что система постоянно тестирует себя

• Netflix может гарантировать клиентам SLA 99.99%, потому что знает, что система может выдержать

Другие примеры Level 5 resilience:

• Amazon: отключает целые data centers и смотрит, что происходит

• Google: случайно вводит баги в код и смотрит, ловит ли их система

• Meta: имитирует network partitions (когда части системы не могут говорить друг с другом) и смотрит, как система реагирует

5. Open innovation и влияние на индустрию

На Level 4 компания держала свои исследования в секрете.

На Level 5 компания публикует свои исследования и становится лидером индустрии.

Почему это выгодно?

1. Привлечение талантов: лучшие инженеры хотят работать в компании, которая публикует исследования и влияет на индустрию

2. Установление стандартов: компания влияет на то, как все остальные делают IT

3. Feedback от community: когда публикуешь исследование, others дают feedback и идеи для улучшения

Примеры:

Google:

• Публикует исследования о ML (TensorFlow, BERT, Transformer)

• Публикует инструменты (Kubernetes, Go язык программирования)

• Результат: Google определяет, как вся индустрия разрабатывает IT

Amazon:

• Публикует об автоматизации, микросервисах, serverless архитектуре

• Результат: AWS стал стандартом облачных вычислений

Meta:

• Публикует об open source (React, PyTorch, Drogon)

• Результат: React — стандарт фронтенда

Netflix:

• Публикует об архитектуре (microservices, chaos engineering)

• Публикует инструменты (Hystrix, Eureka)

• Результат: Netflix определяет, как строить масштабируемые системы

6. Культура постоянной инновации — failure is learning

На Level 1-3 ошибка = плохо, нужно найти виноватого.

На Level 4 ошибка = зафиксировали, добавили тест, закрыли incident.

На Level 5 ошибка = ценный источник знания.

Как это работает:

Blameless culture на стероидах:

Когда что-то ломается:

1. Система автоматически откатывается (downtime < 1 минуты)

2. Система собирает все логи, метрики, инфор��ацию об инциденте

3. Система автоматически запускает post-mortem встречу

4. На post-mortem системе показывает: "Что произошло? Почему? Какие были предупреждающие сигналы?"

5. Система рекомендует: "Давайте добавим этот тест, давайте улучшим этот мониторинг"

6. Система автоматически внедряет рекомендации (если они low-risk)

7. Система отслеживает: "Произойдёт ли это снова?"

Результат:

• Каждый инцидент — это opportunity to learn и improve

• Система становится resilient через trial and error (в production, но с автоматическим rollback)

• Люди не боятся делать large changes, потому что знают, что система их откатит, если что-то пойдёт не так

Количество экспериментов на Level 5:

• Level 3: 5-10 A/B тестов в месяц (люди придумывают идеи)

• Level 4: 50-100 A/B тестов в месяц (люди придумывают идеи, система помогает тестировать)

• Level 5: 1000+ A/B тестов в месяц (система генерирует идеи, система тестирует, люди одобряют)

Результат:

• За год компания пробует 12000+ идей

• 90% не работают (как и ожидалось)

• 10% работают

• Эти 10% приносят сотни миллионов в revenue

7. Люди занимаются стратегией, не операциями

На Level 4 люди занимались:

• 70% тактика (approving deployments, approving optimizations)

• 30% стратегия (thinking about the future)

На Level 5 люди занимаются:**

• 30% тактика (approving big decisions)

• 70% стратегия (thinking about the future, research, innovation)

Что делают люди на Level 5:

Product Leaders:

• Думают о том, какие новые рынки войти

• Анализируют, какие customer segments игнорируются

• Придумывают долгосрочную стратегию (5-10 лет)

• Система предлагает идеи, люди решают, какие идеи pursue

Engineers:

• Работают над research projects (ML, quantum computing, blockchain)

• Пишут paper и публикуют в конференциях

• Работают над 20% projects (Google-style, на личные идеи)

• Системные работы обрабатывают автоматически

Operations:

• Стратегия архитектуры и infrastructure

• Планирование долгосрочной scalability

• Исследование новых технологий

• Система управляет текущими операциями

Result:

• Люди не выгорают (потому что не тушат пожары)

• Люди мотивированы (потому что работают над интересными проблемами)

• Компания инновирует (потому что люди думают о будущем)

Финансовый эффект Level 5

Revenue growth — 50%+ в год

Level 4 компания:

• Growth: 20-30% в год

• Это потому что IT ускоряет существующий бизнес

Level 5 компания:

• Growth: 50-100%+ в год

• Это потому что IT создаёт новые бизнес направления

Примеры:

Amazon:

• Электронная коммерция: $178 млрд в год (2023)

• AWS (облачные сервисы): $80+ млрд в год (2023)

• Advertising: $30+ млрд в год (2023)

• Резервная сумма: другие направления

• Если бы Amazon не внедрила Level 5 IT, AWS никогда не существовала бы

Google:

• Search: $150+ млрд в год

• Advertising (beyond search): $80+ млрд в год

• Cloud: $30+ млрд в год (растёт 25%+ в год)

• Без Level 5 IT, Google остался бы поисковой системой на $50 млрд в год

Netflix:

• Streaming: $40+ млрд в год

• Если бы Netflix не оптимизировала (Level 5), она всё ещё была бы DVD-by-mail компанией на $1 млрд в год

Operational efficiency — 90%+ автоматизация

Level 4:

• 70-80% операций автоматизировано

• 20-30% люди делают вручную

Level 5:

• 90%+ операций автоматизировано

• 10% люди одобряют

Результат:

• Операционные затраты на 40-50% ниже, чем на Level 4

• Для компании с 500 инженеров и 50 млн ₽ на операции:

  • Level 4: 50 млн ₽ на операции для 500 инженеров = 100K ₽ на инженера

  • Level 5: 25 млн ₽ на операции для 500 инженеров = 50K ₽ на инженера

  • Экономия: 25 млн ₽ в год

Innovation velocity — 10x

Level 4:

• 20-50 deployments в день

• Новая фича от идеи до production: 3-5 дней

Level 5:

• 100-200+ deployments в день

• Новая фича от идеи до production: несколько часов (для small changes)

Результат:

• Компания может реагировать на рынок в real-time

• Конкурент выпустил новую фичу? Level 5 компания выпустит аналог за часы

• Customer попросил фичу? Level 5 компания выпустит за день (вместо месяца)

Talent attraction и retention

На Level 5 компания — это лучшее место для работы для инженеров.

Почему?

• Люди работают над интересными проблемами

• Люди работают над research, которая меняет индустрию

• Люди не работают по ночам (система всё чинит)

• Люди лучше платят (потому что компания зарабатывает больше)

• Люди видят результаты своей работы (новые продукты, новые рынки)

Результат:

• Атрация лучших талантов из других компаний

• Низкая текучка (людей не уходят)

• Это даёт компании конкурентное преимущество (лучшие люди = лучший код = лучше продукты)

Типичные компании на Level 5

Очень мало компаний на Level 5. Только те, которые построили IT как ядро бизнеса с самого начала.

Почти-Level 5 компании:

• Amazon: Level 5 для многих систем

• Google: Level 5 для многих систем

• Netflix: Level 5 для streaming

• Meta: Level 5 для ad system и recommendations

• Apple: Level 5 для сервисов (iCloud, AppStore)

• Яндекс: Level 5 для поиска и рекомендаций

Компании, которые ходят достичь Level 5:

• Tesla: хочет сделать всё на Level 5 (cars, manufacturing, software updates)

• ByteDance/TikTok: Level 5 для recommendation algorithm

• Alibaba: Level 5 для search и recommendations

Как достичь Level 5?

Это не быстро и не дешево.

Шаги:

1. Сначала достичь Level 4 (это займет 3-5 лет)

2. Инвестировать в ML и AI (50-100+ инженеров в ML team)

3. Инвестировать в research (университетское сотрудничество, research labs)

4. Культура experimentation (разрешить людям делать mistakes)

5. Open innovation (публиковать исследования, влиять на индустрию)

6. Long-term thinking (думать о 10-летней стратегии, не квартальном результате)

Симптомы Level 5

Innovation is constant, not planned

• Новые фичи выходят постоянно, не по плану

• Каждый день есть что-то новое

Experimentation is automated

• Система генерирует идеи

• Система тестирует идеи

• Люди одобряют результаты

Failure is expected and learned from

• Когда что-то ломается, не ищут виноватого

• Ищут, что можно улучшить в системе

• Улучшение происходит автоматически

People think about the future, not the present

• Engineers работают на research

• Product managers думают о 5-10 годах вперёд, не о квартале

• Operations фокусируется на scalability, не на current operations

Industry leadership

• Компания публикует исследования

• Компания устанавливает стандарты

• Другие компании копируют то, что делает Level 5 компания

Continuous growth

• Revenue растёт 50-100%+ в год

• Это потому что компания постоянно находит новые источники revenue

Выводы

Level 5 — это не конец пути. Это начало будущего.

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

Люди на Level 5 не тушат пожары. Они строят будущее.

Характеристики Level 5:

• Система сама себя оптимизирует (без людей)

• Система сама экспериментирует (без людей)

• Система предсказывает стратегию (люди одобряют)

• Люди работают на research и инновации

• Компания устанавливает стандарты индустрии

Финансовый эффект:

• Revenue growth 50-100%+ в год

• Операционные затраты на 40-50% ниже

• ROI от IT инвестиций 200%+

• Рыночная капитализация растёт экспоненциально

Компании на Level 5:

• Amazon, Google, Netflix, Meta, Apple, Яндекс, ByteDance

Как достичь Level 5:

• Сн��чала достичь Level 4 (3-5 лет)

• Инвестировать в ML и AI

• Инвестировать в research

• Культура experimentation

• Open innovation

• Long-term thinking

---

Заключение всей серии про уровни зрелости IT

Мы прошли долгий путь:

• Level 0: Chaos, никто не знает, что делается

• Level 1: Процессы появились, но люди их игнорируют

• Level 2: Процессы соблюдаются, метрики используются, прогноз ±20%

• Level 3: Процессы автоматизируются, улучшения постоянные, прогноз ±10%

• Level 4: Система управляется ML, люди одобряют, система оптимизирует себя, прогноз ±5%

• Level 5: Система сама инновирует, люди одобряют стратегию, компания создаёт будущее

Главное:

• Каждый уровень требует 12-24 месяца на достижение

• Невозможно прыгнуть через уровни (нужно идти последовательно)

• Каждый уровень даёт exponential returns (Level 2 лучше Level 1 в 2x, но Level 5 лучше Level 1 в 100x+)

• Level 5 — это не финал, это точка, откуда начинается следующее путешествие

Благодарю за внимание! Надеюсь, эта серия помогла вам понять, где находится ваша компания и как двигаться вперёд.

Если у вас есть вопросы, хотите обсудить вашу ситуацию, или хотите помощи в движении на следующий уровень — добро пожаловать в DM.

ТГ @ciologia | vk.com/ciologia