Книгу порекомендовал ментор по курсу "введение в DevOps". Саму ее была то-ли купил, то-ли взял бесплатно по промокоду на литресе несколько лет назад и вот, наконец-то я взял ее с полки, сдул с нее электронную пыль и прочел. Собственно о чем она? Если коротко, то о том, как медленно умирающая компания, внезапно воспряла и стала лидером отрасли. А этому помог в компании вице-президент по информационным технологиям и его армия сотрудников. Сам роман читается легко и буквально с первых страниц погружает читателя в свою атмосферу. При этом меня во время чтения он сильно держал в эмоциональном напряжении, т.к. я сильно переживал за предприятие, героев истории. Слава богу, все закончилось хорошо. Читая, ощущал некое дежавю, что уже чего-то такое где-то встречал. Ну во-первых мне вспомнился "Экстремальный тайм-менеджмент", где к герою приходит наставник и превращает его из обычного обывателя в успешного господина. Еще вспомнился "Атлант расправил плечи", где герои романа трудились и боролись также упорно, как это делает Билл, главный герой романа. Правда, после чтения осталось неприятное послевкусие: 1. Зачем именно наш герой был назначен так высоко. Неужели других кандидатов не было? Или просто герой оказался заложником подковерных корпоративных игр? 2. А что если бы действие происходило в русскоязычной стране, то боролся бы так самоотверженно и неделями с проблемами бизнеса герой, который оброс семьей и ему уже больше 40 лет? Т.к. девопс с технической стороны и его роли в разработке программного продукта мне знаком, я больше узнал про методику управления проектом "канбан". При этом авторы в художественный смысл вплели случай "было" (авралы, вечное тушение пожаров и пр) и "стало" (четко выстроенная система выполнения задач с приоритетами). Еще книга мне шире открыла глаза на то, что современный бизнес очень сильно зависим от айти, которое сейчас везде, а не только при разработке каких-то систем продуктовыми компаниями или поддержке и сопровождении чего-то на аутсорсе сервисной компанией. Собственно, прежде всего, можно порекомендовать эту книгу двум категориям людей: 1. которые только пришли в эту динамично изменяющуюся сферу, чтобы они поняли свое назначение на рабочем месте, в мире (правда, если читатель работает в государственной организации, то что тогда?) 2. люди из бизнеса, которые хотят понять птичий язык этих модных ребят в шортах и футболках из соседнего отдела и как они помогают бизнесу компании. Книгу не воспринимайте близко как руководство к действию. Это больше первый шаг, на пути к знакомству с методиками ведения проектов и набором практик девопс. Все-таки это не человек, который поддерживает инфраструктуру и помогает настроить доставку кода с редактора на экране лаптопа до определенного контейнера в сложной инфрастуктуре. А именно это набор практик, которое помогает обеспечить функционирование сложной среды переплетенных между собой множества корпоративных приложений. В "Проект "Феникс" есть отсылки к книгам, где рассказывается про методологии ведения проектов, несколько раз упоминается роман "Цель". Так что буду знакомиться и с этими книгами тоже.

Интересный роман, однако практическая польза от прочтения выглядит сомнительной. Дело в том, что в книге описывается компания, в которой вообще не было никакой автоматизации внутри IT: ни системы контроля версий, ни TFS, ни confluence, ни сборочного конвейера, ни непрерывной интеграции. В таких условиях, конечно, легко проводить революцию. Практически любые адекватные изменения будут приводить к существенному росту производительности IT-подразделения, потому что, как еще говорят, с нуля расти легко, показывая невероятные проценты роста.В современном мире сложно найти компанию, которая работала бы в таких первобытных условиях.Сюжет романа неоднократно перекликается с некоторыми моментами из книги Цель Голдрата. В этом плане книга позволяет закрепить знания по теории ограничений, поэтому читать ее конечно лучше после Целей.

Наконец-то я дочитал книгу Проект Феникс – книгу, которая по мнению комьюнити должна дать ответы на какие-то сакральные вопросы. Среди окружающих меня людей достаточно много кто ее рекомендовал к прочтению с формулировками в духе “она тебе даст понимание того, что же такое DevOps на самом деле” – я же DevOps-инженером никогда не работал.Впервые я прочитал ее около двух лет назад. И с тех пор у меня мало чего изменилось в отношении данной книги. Если рассматривать ее как художественную литературу с некоторым количеством технических терминов, то в целом – да, однозначно интересная книга, которая достаточно легко читается буквально на одном дыхании. И если в прошлый раз я ее действительно прочитал залпом, то в этот раз у меня ушло около полутора недель потому что я делал заметки по прочитанному материалу (по которым выйдет отдельный лонгрид в блоге).Для меня лично книга Проект Феникс, в очередной раз, стала подтверждением того, чем для меня и являлся этот ваш DevOps. А DevOps для меня как был так и остался – не столько методологией, сколько “коммуникацией и взаимопониманием”. Да, я даже после повторного прочтения этой замечательной книги говорю снова то же самое. DevOps – это про коммуникацию и взаимопониманием. Тут довольно большое количество тех, кто работал и работает DevOps-инженерами и они могут начать кидать в меня свои тапки, но пусть мне хоть один DevOps-инженер попробует доказать, что описанное в книге (достижение показателей бизнеса и разрушение барьеров между эксплуатацией, разработкой, тестированием, инфобезом и бизнесом) возможно без соблюдения двух важнейших идей – коммуникация и взаимопонимание – комментарии открыты.Если проследить сюжетную линию, то DevOps (который внедрил главный герой) был достигнут благодаря следующему (крупными мазками) – разрушение барьера между разными подразделениями (между эксплуатацией, разработкой, тестированием, инфобезом и бизнесом) с уточнением основных болей (которые причиняют коллеги друг другу) и ожиданий друг друга, а так же совместное нахождение решений (которые устроят всех ключевых участников) для упомянутых болей и глобальное (по меркам компании) переосмысление значимости ИТ-подразделений в структуре компании. Исключительно и благодаря попыткам разобраться задавая вопросы (коммуницируя) и понимая чужие точки зрения (не принимая, а именно понимая их) был достигнут огромный результат.Я как человек, который занимается именно эксплуатацией уже более десяти лет, могу сказать только одно – ваш DevOps это не про CI и CD, не про пайплайны и релизы. DevOps – это куда большее! DevOps – это про открытость, коммуникацию, взаимопонимание, взаимовыручку! А называть это DevOps’ом или как-то еще – какая разница?! Пойми, что и ты и “эти долбанные разрабы” вместе с “ничего не понимающими менеджерами” и “специалистами по безопасности” – вся эта толпа чтобы добиться общего успеха должна научиться разговаривать на одном языке, должна уметь общаться, делиться знаниями и опытом, слышать и слушать друг друга, выручать друг друга и помогать друг другу.