Рецензия на книгу
«Ускоряйся! Наука DevOps»

Досталась мне почитать книга из ныне популярного набора. «Ускоряйся! Наука DevOps. Как создавать и масштабировать высокопроизводительные цифровые организации» — книга, которая позиционируется как путеводитель в мире IT, позволяющий внедрить так называемые лучшие практики.

О! То есть те самые инженерные практики, которые по-хорошему нужны всем и каждому в тех самых цифровых организациях. При этом самому принципу DevOps в книге уделяется подозрительно мало времени.

Приводится множество рассуждений и выводов из 4-летнего исследования эффективности поставки программного обеспечения, в котором успешность зависит от частоты поставки. Человека непосредственно из разработки это уже заставляет задуматься о целесообразности самого процесса того самого исследования.

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

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

Собственно, той самой архитектуре посвящено аж две главы. С упором на слабую связанность (сразу вспоминаются микросервисы, такое чувство, что авторы и подопытные никогда не работали с большими системами и не отслеживали цепочку сообщений внутри) и наличие того самого гуру, который в целях исключения бас-фактора не один, а целая команда. Нуу, допустим, ок. Если вы можете в своем IT-департаменте выделить таких людей, вам остаётся только позавидовать. А если вас 5 человек на огромную паутину, то, увы, либо все знают всё, либо один архитектор и один его замещающий разработчик.

Глава 4. О сколько нам открытий чудных готовит непрерывная доставка!
Тут и автотесты, и контроль версий, и непрерывная интеграция и все прочие прелести. Прямо волшебная кнопка "сделать всё хорошо". Она, кстати, реально работает на уже более высоком уровне сознательности, когда разработчик, уходя домой, не оставляет открытой IDE, а выкладывает в репозиторий уже готовый протестированный им самим код, а утром проверяет, как прошло слияние, тестирование и разбирается, если что-то пошло не так. Автоматизация рутины — это прекрасно, но и ручками поработать иногда надо (ура, я нашла девопс).

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

Главы о культуре рассказывают, как культура в организации влияет на рабочий процесс. Также авторы говорят, что "можно влиять на культуру и улучшать ее путем внедрения методов DevOps.". Как влиять, при этом, не указывается сразу, ищите дальше. Да-да, а сразу сделать отсылку к наставничеству нельзя было. И всё-таки, при чём тут девопс? Типа команду делаем из админа и программера?

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

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

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

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

Автор: Анастасия Тельных, старший программист ЕвроАвто
Книга: Форсгрен Н., Хамбл Д., Ким Д. «Ускоряйся! Наука DevOps: Как создавать и масштабировать высокопроизводительные цифровые организации»

Ещё больше материалов в Telegram-канале @pmclub