Только что дочитал «The Phoenix Project». Нашёл там знакомые проблемы и системные паттерны, с которыми сталкивается любой руководитель ИТ при масштабировании.

Знаю, про эту книгу уже все слышали. Но я добрался до неё только сейчас и пожалел, что не сделал этого лет пять назад. Это практическое руководство по управлению сложностью в ИТ, упакованное в захватывающий сюжет.

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

Несколько идей, которые раскрывает книга на уровне систем:

✓ Узкое место определяет скорость всей системы. Пока все бегут быстрее, а «бутылочное горлышко» не найдено — толку не будет.

✓ Вся работа в ИТ делится на четыре типа. Самый коварный — «незапланированная работа» (пожары, инциденты). Если её больше 30%, компания не развивается, а выживает. Задача руководства — смещать этот баланс через автоматизацию и процессы.

✓ Знаменитые «Three Ways» DevOps. Авторы объясняют их как философию: 1) ускорить поток работы от идеи до продакшена (это про архитектуру и CI/CD), 2) быстро ловить сбои (это про культуру и мониторинг) и 3) не бояться экспериментировать (это про доверие и инновации).

Кому стоит прочитать: ✓ Всем, кто управляет ИТ-командами — от тимлида до CTO.

✓ Бизнес-лидерам (CEO, CPO, CFO), которые хотят наконец понять, как измерить вклад ИТ в бизнес-метрики, а не только видеть список затрат. Книга учит говорить с технарями на одном языке.

✓ Тем, кто хочет занять позицию CTO/VPE. Лучше один раз прожить этот хаос в книге, чем наступать на те же грабли в реальности.

Ловил рабочие флешбеки по несколько раз за главу. Та же борьба с легаси, те же ночные созвоны из-за падения сервисов, те же разговоры с советом директоров про SLA и отчётность.

Советую тем, кто может — читать в оригинале. В русском переводе, как пишут, многие концепции теряют точность.

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