Архив рубрики: DevOps

Книга: The Phoenix Project

clip_image002[7]Итак, я добрался до Святая Святых девопса – бЫзнес-романа The Phoenix Project. Снова прозреваю, что кроме меня его уже все читали. Так что я снова коротенько по задевшим лично меня моментам, равно как и по непонятным или смешным.

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

Есть три путя:

1)      Никакой локальной оптимизации, никакого «с моей стороны пуля вылетела». Делаем мелкими партиями, никогда не передаём дефектный код дальше. Инструментарий:

a.       Continuous build, integration and deployment.

b.       Создание окружений по запросу.

c.       Ограничение WIP.

d.       Построение safe systems and organizations that are safe to change. Вот этот кусок несколько абстрактен. Прозреваю, что пойму, когда настанет пора (или когда прочитаю DevOps Handbook J).

2)      Построение обратной связи. Не очень понятно, как мне это делать в своей ситуации. Тоже нужно разбираться.

a.       Остановка production line когда тесты и билды фейлятся. Здесь всё просто относительно, если мы качественно разберёмся с пп.1 и 2d.

b.       Постоянно улучшать работу даже в ущерб повседневной работе. Всё понятно, но нужно где-то взять политической воли. Есть взаймы у кого-нибудь? =)

c.       Создание быстрых автотестов, подтверждающих, что код всегда готов к деплою.

d.       Создание общих целей между Dev & Ops.

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

3)      Создание культуры, которая пестует постоянные эксперименты и учёбу на ошибках и успехах.

a.       Создание культуры инноваций и принятия риска. Вот тут ещё учиться и учиться. Мне.

b.       Выделение хотя бы 20% времени на постоянное улучшение. Как показал эксперимент, тупо выделение этого времени не работает. Нужно предыдущий подпункт корректировать, да и ещё чего-то может не хватать.

Хотя везде идёт рефреном «break the silos», всё равно эта история – про повышение ответственности той части команды, которая пишет код продуктов. Автоматизация релизов просто не оставляет других шансов. Если ручное развёртывание Ops’ами релизов ещё как-то нивелирует последствия плохого кода или тестирования (админ может руками что-то откатить или допилить на лету вместе с разработчиком), то полная автоматизация должна это сделать сама. Нет, понятно, что разбудить админа, чтобы он починил, всё равно можно, но это дополнительное время простоя. Немного нивелируется это тем, что теперь ответственность Ops за инфраструктуру именно доставки кода и окружений также становится очень высокой. На самом деле, надёжность этого куска должна быть, кажется, запредельной. Чуть ли не выше доступности самих продуктов.

Автоматизировать всё нужно даже не для сокращения издержек, а для того, чтобы разрабы могли сами получать окружение, похожее на продуктив. Чтобы прохождение тестов на stage-среде действительно было маркой качества: развёртывание в бой не сорвётся. И чтобы переиспользовать эту экспертизу для разных команд разработки.

Вопросы:

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

1)      Почему разделяются бизнес и технические проекты? Обновление почтовой системы – технический проект? Но там есть функционал для бизнеса, допустим. В общем, мне это деление кажется несколько условным.

2)      Проекты состоят из изменений, почему мы их, опять же, разделили?

Из занятного: снова появляется Русская Мафия, которой с придыханием нужно продать данные ваших клиентов, украденные хакерами. Всё-таки к Медведю с Балалайкой мы, похоже, добавляем ещё один национальный бренд. =)

Легко ли читать: Да, легко и интересно. Всё-таки, это больше художка, и не так, чтобы плохо написанная.

clip_image004

Полезность: выше средней. Прорыва у меня пока нет, всех ответов нет. Нужно следующее читать. Но и зря потраченным временем это не назвать – польза однозначно есть.

clip_image006