Джордж Спаффорд - Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему
- Название:Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему
- Автор:
- Жанр:
- Издательство:Array Литагент «5 редакция»
- Год:2015
- Город:Москва
- ISBN:978-5-699-77536-1
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Джордж Спаффорд - Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему краткое содержание
Новая IT-инициатива компании под кодовым называнием «Проект Феникс» имеет критическое значение для Parts Unlimited, но проект явно выходит за рамки возможностей бюджета и очень сильно не укладывается в сроки. Генеральный директор хочет, чтобы Билл уладил все проблемы за 90 дней, или же весь отдел Билла будет уволен. С помощью перспективного члена команды и своей мистической философии Трех Путей Билл начинает видеть, что работа в IT имеет гораздо больше общего с работой завода, чем он когда-либо мог представить. Часы тикают, и Билл должен наладить связи между разными отделами компании, правильно выстроить работу и эффективно решить бесчисленные проблемы, возникающие в Parts Unlimited.
В легком и развлекательном стиле авторы рассказывают историю, которая знакома всем, кто когда-либо работал в IT. Читатели не только узнают, как использовать методологию DevOps в своих компаниях, они уже никогда не посмотрят на IT прежними глазами.
Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
К сожалению, я себе этого представить не могу. «Продолжай в том же духе. Убедись, что и Вэс тоже принимает в этом участие, ладно?»
«Он уже, – отвечает она быстро. – Сегодня мы с ним встречаемся, чтобы обсудить возможность применения канбан, с целью еще больше изолировать Брента от ежедневных кризисов. Я хочу формализовать рабочий процесс Брента и таким образом увеличить наши возможности стандартизации того, над чем он работает. Это даст нам возможность понять, откуда берется его загруженность. И конечно же, это даст нам еще одну линию защиты от людей, которые хотят использовать его везде и всюду по своему усмотрению».
Я показываю ей большой палец и уже готов уйти. «Подожди-ка, доска изменений выглядит по-другому. Почему карточки разных цветов?»
Она смотрит на доску и говорит: «Ой, я тебе не сказала? Мы ввели цветовые различия для карточек, чтобы помочь себе подготовиться к тому моменту, когда мы снимем заморозку с проектов. Нам нужен был способ контролировать процесс – быть уверенными, что мы работаем над самыми важными проектами. Поэтому теперь система такая: сиреневые карточки – это изменения, которые поддерживают пять топовых бизнес проектов, все остальные – желтые. Зеленые карточки – это внутренние проекты по совершенствованию IT-инфраструктуры, под которые мы отводим теперь около двадцати процентов нашего времени по совету Эрика. На первый взгляд кажется, что сейчас мы соблюдаем правильный баланс сиреневых и зеленых карточек».
Она продолжает: «Розовые стикеры обозначают карточки, которые по какой-то причине были заблокированы, и их мы пересматриваем дважды в день. И мы снова заносим все эти карточки в нашу программу отслеживания изменений, поэтому мы записываем ID изменений на каждую карточку. Это довольно утомительно, но, по крайней мере, уже часть процесса отслеживания автоматизирована».
«Ничего себе, это… невероятно», – говорю я, искренне пораженный.
Позже в этот день я сижу за еще одним столом переговоров с Вэсом и Патти, выясняя, как мы можем запустить снова все проекты так, чтобы мы, образно говоря, могли пить, но не захлебнулись.
«Как показал Эрик, у нас есть две очереди проектов, которые нужно последовательно выполнять: бизнес-проекты и внутренние, – говорит Патти, показывая на тонкую стопку листов перед нами. – Давайте сначала рассмотрим бизнес-проекты, потому что с ними проще. Мы уже смогли определить топ-пять наиболее важных проектов. Четыре из них потребуют той или иной помощи от Брента. Когда мы снимем заморозку, мы займемся только этими пятью проектами».
«Это было совсем просто, – смеется Вэс. – Не могу поверить, через сколько споров, обвинений, хитроумных политических торгов и предательств нужно было пройти, чтобы определить пять топовых проектов. Это было похуже гангстерских разборок!»
И он прав. Но, в конце концов, мы смогли составить список приоритетов.
«Теперь к сложному. Мы все еще бьемся над тем, как расставить приоритеты среди семидесяти трех внутренних проектов, – говорит Патти, ее лицо становится угрюмым. – Их все еще слишком много. Мы провели недели со всеми руководителями команд, пытаясь создать некоторый список относительных уровней важности, но это все, что мы сделали. Споров было очень много».
Она перелистывает на вторую страничку. «Кажется, что проекты можно разделить на следующие категории: замена уязвимой инфраструктуры, обновления от производителей и поддержание внутренних бизнес-требований. Все остальные проекты – это сборная солянка из аудита и работ с системами безопасности, работа по обновлению баз данных и так далее».
Я смотрю на второй список, почесывая голову. Патти права. Как мы можем объективно решить, что важнее – «консолидация и обновление почтового сервера» или «обновление тридцати пяти инстанций баз данных SQL»?
Я быстренько пробегаюсь по странице – может, что-нибудь само попадется на глаза. Это тот же список, что я видел в первую неделю своей работы, и все эти проекты все еще остаются актуальными и важными.
Осознав, что Вэс и Патти провели практически неделю, сидя над этим списком, я пытаюсь подумать о ситуации в другом ключе. Должен существовать простой способ расставить приоритеты в этом списке.
Внезапно я вспоминаю, как Эрик описывал важность превентивной работы, вроде нашего мониторингового проекта. Я говорю: «Мне не важно, насколько все думают, что их проект важен. Нам нужно знать, увеличивают ли эти проекты пропускную способность нашего бутылочного горлышка, а это все еще Брент. Если проект не снижает нагрузку на него, возможно, нам и не стоит его осуществлять. С другой стороны, если для проекта и не нужен Брент, то нет и причин, по которым мы не можем его выполнить. – Я говорю убежденно, – Составьте мне три списка. Один – это те проекты, которые требуют работы Брента, другой – те проекты, которые увеличивают отдачу Брента, и последний – куда войдет все остальное. Определите самые важные проекты в каждом списке. Не отводите слишком много времени на их обсуждение – не хочу, чтобы мы снова потратили дни на споры. Самый важный список – это второй. Мы должны увеличивать возможности Брента, снижая количество незапланированной работы, которая вредит ему».
«Это звучит знакомо, – отвечает Патти. Она находит список уязвимых сервисов, который мы создали для процесса контроля изменений. – Мы должны убедиться, что у нас есть проект на замену и для стабилизации каждого из выписанных здесь сервисов».
«Теперь подождите-ка еще минутку, – говорит Вэс. – Билл, ты говорил это сам. Превентивная работа важнее, но она все время откладывается. Мы пытались осуществить некоторые из этих проектов годами! Это наш шанс наконец-то доделать их».
Патти быстро говорит: «Ты не слышал, что Эрик сказал Биллу? Усовершенствование, осуществляемое где-то, кроме бутылочного горлышка, – это иллюзия. Ты знаешь, без обид, но ты похож на Джона сейчас».
Несмотря на все свои усилия, я начинаю смеяться.
Вэс краснеет, но затем тоже громко смеется. «Упс. Ладно, ты меня поймала. Но я лишь пытаюсь сделать все правильно. Черт! – говорит он, прерывая сам себя. – Я снова похож на него».
Мы все смеемся. Но это заставляет меня снова подумать о том, как дела у Джона. Насколько я знаю, за целый день никто ни разу его не видел.
Пока Вэс и Патти собирают записи, я снова просматриваю список внутренних проектов. «Слушайте, а почему здесь проект по обновлению базы данных BART, хотя ее списывают в следующем году?»
Патти, заглядывая в список, выглядит смущенной. «Ох, господи, я его не заметила, потому что мы никогда не сопоставляем бизнес– и IT-проекты друг с другом. Нам нужно будет еще раз прошерстить эти списки, чтобы найти зависимости вроде этой. Уверена, найдутся и другие».
Читать дальшеИнтервал:
Закладка: