Проект «Феникс». Роман о том, как DevOps меняет би - Страница 34

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

Я слушаю идеи Патти и Вэса и потом говорю: «Давайте вернемся к нашим целям: собраться вместе и узнать, что делают другие сотрудники, разобраться в ситуации, держать руку на пульсе и дать аудиторам доказательства того, что мы взяли процесс контроля изменений в свои руки.

Нам нужно сфокусироваться на наиболее рискованных изменениях, – продолжаю я. – Правило 80/20 в этом случае работает так: двадцать процентов изменений несут восемьдесят процентов риска».

Я снова смотрю на кучки карточек перед нами и вытаскиваю пару наугад, пытаясь хоть чем-то вдохновиться.

Держа в руках карточку, на которой нарисовано большое хмурящееся лицо, я спрашиваю: «Что такое PUCCAR?»

«Это бесполезное приложение, – говорит Вэс с отвращением, – это приложение Parts Unlimited, которое проверяет клиринг чеков и соответствие банковским требованиям, которое кто-то установил почти два десятка лет назад. Мы зовем его «пукер», потому что каждый раз, когда его хоть немного меняешь, оно взрывается, и никто не знает, как наладить его работу. Производитель отошел от дел черт знает сколько лет назад, но мы никак не можем его заменить, потому что нет финансирования».

Я спрашиваю: «Если мы знаем, что это приложение все время рушится, зачем его изменять?»

Вэс быстро отвечает: «Мы пытались этого не делать. Но иногда бизнес-правила меняются, и мы тоже должны им следовать. Оно работает с операционной системой, которая уже не используется, поэтому это всегда немного сложно…»

«Понятно! Это рискованное изменение. Какие еще изменения вроде пукера вы предложили?»

Мы складываем отдельную кучку из примерно пятидесяти карточек, предлагающих изменения в приложения Rainbow, Saturn или Taser, а также изменения сети и определенных баз данных, которые могут затронуть часть или даже весь бизнес.

«Даже глядя только на эти карточки, я чувствую, что у меня сердце сейчас выскочит, – говорит Вэс. – Некоторые из этих изменений очень опасны».

Он прав. Я говорю: «Ладно, давайте эти все назовем «Хрупкие изменения». Это изменения, связанные с высоким риском, их нужно авторизовывать у CAB. Патти, подобные изменения всегда должны быть в приоритете на наших встречах».

Патти кивает, все записывая, и говорит: «Поняла. Мы вывели категорию изменений высокого риска, на которые надо не просто подать запрос, но и авторизовать до выполнения».

Мы быстро создали список десяти наиболее хрупких сервисов, приложений и инфраструктур. Любое изменение, которое затрагивает какую-либо из этих систем, требует одобрения CAB.

Патти добавляет: «Нам нужно создать какую-то стандартную процедуру для этих изменений, а также найти людей, которые будут не просто знать, но и отвечать за них, если что-то пойдет не так».

Она добавляет с улыбкой: «Ну, вы знаете, вроде как пожарные и «Скорая», которые ждут на посадочной полосе, готовые заливать самолет специальной пеной, когда он приземлится, весь в огне».

Вэс смеется и говорит: «Да, а в случае с PUCCAR нужно еще пригласить кучку следователей и мешков для трупов. И пиарщика, который уже готов отвечать на злобные звонки из бизнес-отдела, говоря, что у некоторых спасаемых нами клиентов была аллергия на используемую нами пену для тушения».

Я смеюсь. «Вы знаете, а это интересная идея. Давайте позволим бизнесу выбрать эту самую пену. Нет причины, по которой вся ответственность должна ложиться на наши плечи. Мы можем отсылать письмо бизнес-руководству с вопросом, когда лучшее время для наших работ. Если мы сможем предоставить им данные о результатах предыдущих изменений, они возможно отложат запланированное».

Мне очень нравится идея Патти, и я уверен, что мы на правильном пути. «Ладно, но у нас все еще остается четыре сотни карточек. Идеи?»

Вэс в это время методично разбирал карточки, раскладывая их на две кучки. Он берет карточку из большей кучи: «Это стопка изменений, которые мы делаем постоянно. Вроде обновления налоговых ставок в системе POS. Не думаю, что мы должны их опасаться.

С другой стороны, изменения вроде «увеличение тред пула Java-приложений» или «установка пакета исправлений от поставщика Kumquat для решения проблем с производительностью».

«Что нам со всем этим делать? – говорит Вэс. – Я просто недостаточно компетентен в этих вопросах, чтобы действительно что-то решать. Я не хочу быть такой чайкой, которая прилетает, испражняется на людей и потом улетает, понимаете?»

Воодушевленная, Патти говорит: «Отлично! Первая группа – это изменения с низкой вероятностью риска, то, что называется «стандартные изменения». Это изменения, которые мы осуществляли много раз удачно, их мы заранее одобряем. Их по-прежнему нужно будет вносить, но проводить можно и без собрания».

Когда все кивают, она продолжает: «И у нас остается около двухсот изменений средней степени риска, которые нам нужно рассматривать».

«Я согласен с Вэсом, – отвечаю я. – В этих случаях мы должны довериться тому руководителю, в чьей группе они проводятся, так как он или она знают больше. Но я бы хотел, Патти, чтобы сотрудники продолжали информировать всех, кого их действия могут затронуть, и получали ОК ото всех этих людей».

Некоторое время я думаю и говорю: «Возьмите приложение Джона. Прежде чем запрос на такое изменение поступил бы к нам, нужно было, чтобы он получил согласие ото всех владельцев приложений и баз данных, а также от бизнес-отдела. Если бы он это сделал, для меня этого было бы достаточно. Наша роль видится мне в том, чтобы убедиться, что все точки над «i» расставлены. На этом уровне меня больше беспокоит интеграция процессов, а не сами изменения».