Файл: Дэвис Дженнифер, Дэниелс КэтринД94 Философия DevOps. Искусство управления it. Спб. Питер, 2017. 416 с. ил. Серия Бестселлеры OReilly.pdf

48
Часть I. Основы devops

предоставит больше времени на решение новых задач, благодаря чему по- явятся дополнительные инновации.
Как только истории об опыте применения devops станут всеобщим достоянием, они окажут влияние на отрасль в целом. В результате появятся новые возможно- сти и знания, а также станет возможным обмен знаниями.
Devops-пакт
Подлинный devops-пакт имеет место только тогда, когда люди не просто работают вместе в одной группе, а формируют единую команду. Если участники команды постоянно сообщают друг другу о своих намерениях и возникающих проблемах и постоянно подстраиваются с учетом общих целей организации, формируется так называемый devops-пакт.
Пример пакта
Чтобы представить себе критически важный пакт, рассмотрим общение между двумя скалолазами, которое заключается в обмене информацией, уточнении спорных моментов и формировании взаимного доверия. Суть скалолазания за- ключается в перемещении по скалам и искусственным сооружениям в разных направлениях. Скалолазу нужно достичь верхней или конечной точки маршрута и не сорваться при этом. Для достижения этой цели понадобится как физическая выносливость, требуемая для решения возникающих проблем, так и умственная активность, необходимая для понимания сути проблемы и подготовки к выполне- нию следующих действий.
Обычно в процессе скалолазания скалолаз, выполняющий восхождение (восходи-
тель), использует трос и карабин для страховки от возможного падения. Напарник восходителя контролирует степень натяжения троса. Он должен натягивать его достаточно сильно во избежание падения, но в то же время давать слабину, необ- ходимую для обеспечения свободы маневра.
Обеспечение правильной и безопасной страховки требует от страхующего напар- ника как понимания используемых инструментов и процессов, так и обеспечения постоянной связи со скалолазом, выполняющим восхождение. Восходитель дол- жен надежно прикрепить страховочный трос к карабину. Страхующему напарнику нужно убедиться в том, что страховочное устройство надежно закреплено с помо- щью карабина. Между скалолазами устанавливаются доверительные отношения, но прежде чем приступать к восхождению, нужно еще раз все проверить.
При восхождении используется набор словесных ключей, позволяющих прове- рить готовность к процессу восхождения. Сначала восходитель спрашивает у на- парника: «На страховке?» Напарник отвечает: «На страховке». Затем восходитель говорит: «Подъем!», сигнализируя о готовности к началу восхождения. И наконец,

Глава 2. Определение devops
49
напарник подтверждает осведомленность о готовности восходителя, произнося слово «подъем».
Для обеспечения работоспособности этого пакта применяются следующие прин- ципы:

общие четко сформулированные цели;

непрерывное общение;

динамическая настройка и коррекция понимания.
Как будет показано в следующих разделах, соблюдение этих принципов необходи- мо как для внедрения devops на рабочем месте, так и для успешного восхождения на горную вершину.
Пример devops-пакта
Представьте себе, что два сотрудника компании Sparkle Corp работают в разных командах. Сотрудник по имени Дженераль является старшим разработчиком, обладает множеством рабочих навыков и работает в компании Sparkle Corp уже два года. Джордж работает в отделе техподдержки, обладает некоторыми рабочими навыками и является новичком в компании Sparkle Corp.
Команды, в которых работают эти два сотрудника, поддерживают глобальное сооб- щество людей, использующих сайт компании Sparkle Corp для реализации своих творческих начинаний. Общая цель, стоящая перед этими командами, заключается во внедрении нового средства, которое увеличивает ценность сайта компании для конечных пользователей, не оказывая на него негативного влияния.
Обладая большим опытом работы в компании, Дженераль дает четкие указания
Джорджу об ожиданиях, ценностях и процессах, имеющих место в компании
Sparkle Corp. В свою очередь Джордж может в любой момент обратиться к Джене- раль с просьбой о помощи или в случае непонимания какого-либо производствен- ного нюанса. Прежде чем перейти к следующему этапу производственного процес- са, Дженераль и Джордж контролируют результаты работы друг друга. Подобная проверка является примером модели «доверяй, но проверяй», используемой при описании процесса скалолазания.
Как Дженераль, так и Джорджу присуще понимание общих целей:

внедрение нового инструмента, увеличивающего ценность для заказчиков компании Sparkle Corp;

поддержка безопасности и доверия при осуществлении взаимного обмена информацией.
В изолированной среде, не использующей принципы devops, понимание общих це- лей отсутствует. Это может привести к тому, что, например, Дженераль попытается

50
Часть I. Основы devops приступить к кодированию, не убедившись в том, что Джордж понял суть требо- ваний. В этом случае совместная работа возможна, но без обмена информацией о намерениях шансы на успех уменьшаются.
Безусловно, в любой организации могут возникать неожиданные проблемы или препятствия, но при наличии общего понимания целей каждый сотрудник яв- ляется частью пакта, а предпринимаемые действия направлены на выполнение текущего «ремонта». Мы «ремонтируем» наше недопонимание, связанное с вы- бором исполнителей работ по разработке конкретного инструмента или сроков выполнения работы. Мы устраняем ошибки, влияющие на наше понимание пред- полагаемого поведения программного обеспечения. Мы «ремонтируем» процессы и сопровождающую документацию, если дела в производственной сфере идут не так, как ожидалось.
На протяжении всей книги мы будем использовать идею о devops-пакте. Мы также продемонстрируем, каким образом технологические и культурные аспекты devops становятся способами развития и поддержки общего взаимопонимания.

ГЛАВА 3
История devops
Чтобы лучше понять причины, которые привели к зарождению и развитию движе- ния devops, нужно рассмотреть историю разработки ПО, а также повторяющиеся паттерны и идеи, применяемые в этой области. Вооруженные этими знаниями, мы можем представить, где находимся в данный момент. Мы осознаем, каким образом с помощью эффективных devops-способов можно разорвать порочный круг расширения специализации, приводящий к созданию изолированных сред и девальвации конкретных ролей.
Разработчик в качестве оператора
Изначально разработчик программ являлся оператором. На исходе Второй миро- вой войны правительство США обратилось к ведущим математикам с призывом создать «компьютеры». Эти устройства должны были применяться для расчета баллистических таблиц, используемых при стрельбе. На этот призыв откликну- лись женщины-математики, и среди них была Джин Бартик. Она пренебрегла возражениями своего преподавателя колледжа, который считал, что решение повторяющихся задач не столь важно, как продолжить семейную традицию и по- лучить классическое образование.
Иногда полезно выслушать совет и сделать по-своему. Джин Бартик оказалась на нужном месте в нужное время и стала одним из первых программистов компью- тера ENIAC.
Используя анализ аппаратных и логических схем, Бартик и пять ее коллег-програм- мистов смогли научиться программировать на компьютере ENIAC, и это при полном отсутствии сопровождающей документации. Программирование на этом компью- тере, работающем на 18 тысячах радиолампах, осуществлялось путем вращения дисков и изменения кабельных подключений с помощью 40 управляющих панелей.
В те времена для обеспечения работы компьютеров вместо программирования ис- пользовалась аппаратная инженерия. В случае возникновения проблем инженеры

52
Часть I. Основы devops заявляли о том, что причина появления проблем заключается не в машине, а в опе- раторе. Программисты несли на себе бремя ответственности за управление и экс- плуатацию компьютеров. Им приходилось заменять предохранители и кабели, а также устранять синтаксические ошибки в программах.
Появление программной инженерии
В 1961 году президент США Джон Кеннеди провозгласил амбициозную лунную программу. В рамках этой программы в течение ближайших десяти лет должен был состояться полет человека на Луну с последующим благополучным возвращени- ем на Землю. Учитывая сжатые сроки и отсутствие специалистов, которые могли бы создать необходимое программное обеспечение, NASA объявило о наборе профессиональных программистов. Проект NASA по разработке ПО возглавила математик из Массачусетского технологического института Маргарет Гамильтон
1
Как вспоминает Гамильтон:
Процесс генерирования новых идей превратился в настоящее приключе- ние. Везде царили самоотверженный труд и ответственность. Атмосфера взаимного уважения способствовала комфортной работе. Поскольку процесс разработки ПО носит мистический характер, являясь чем-то вроде «черного ящика», топ-менеджмент предоставил нам полную свобо- ду и оказал абсолютное доверие. Мы должны были найти эффективный способ создания программ, и мы сделали это. Оглядываясь назад, я хочу сказать, что мы были счастливейшими людьми в мире. У нас не было другого выбора, кроме как стать первыми в мире, и не было времени на то, чтобы пребывать в состоянии «чайников»
2
Поскольку Гамильтон была известна стремлением к созданию сложного программ- ного обеспечения, ей приписывают создание термина программная инженерия.
Она также разработала приоритетные дисплеи, программное обеспечение, преду- преждающее астронавтов о наличии информации, которая требует реагирования в режиме реального времени. Маргарет разработала набор правил по сбору требо- ваний, один из пунктов которого заключался в обеспечении качества как одного из методов программного инжиниринга. Список методов программной инженерии включал следующие позиции:

отладка всех отдельных компонентов;

тестирование отдельных компонентов до этапа сборки;

интеграционное тестирование.
1
Robert McMillan, «Her Code Got Humans on the Moon — And Invented Software Itself», WIRED,
October 13, 2016.
2
A. S. J. Rayl, «NASA Engineers and Scientists — Transforming Dreams Into Reality», 2008, http://
www.nasa.gov/50th/50th_magazine/scientists.html.

Глава 3. История devops
53
В 1969 году во время осуществления миссии «Аполлон-11» произошел сбой бор- тового компьютера из-за большого объема выполняемых вычислений. Команда разработчиков предусмотрела возможность вмешательства астронавтов в процесс управления модулем в обход бортового компьютера. Это позволило Нейлу Арм- стронгу в критической ситуации взять управление лунным модулем на себя.
Благодаря свободе и доверию, предоставленным менеджерами группе инженеров- разработчиков ПО, а также взаимному уважению, царившему в группе разработ- чиков, стало возможным создание программного обеспечения, способствующего достижению величайших технологических успехов, таких как высадка Нейла Арм- стронга на Луну. Если бы в среде разработки ПО отсутствовало взаимное доверие, вряд ли была бы реализована критически важная функция ручного управления лунным модулем. Если бы не эта функция, вряд ли лунная эпопея завершилась бы благополучно.
ПРОБЛЕМЫ, СВЯЗАННЫЕ С ПРОГРАММНЫМ ОБЕСПЕЧЕНИЕМ
В 60-е годы XX века космические полеты были не единственной областью, в ко- торой применялось программное обеспечение. По мере того как оборудование стало более доступным, начало вызывать тревогу постоянно усложняющееся программное обеспечение. Эта сложность не соответствовала стандартам, при- нятым в других инженерных дисциплинах. Быстрый рост сложности систем и возрастающая зависимость от них начали беспокоить пользователей.
В 1967 году Научный комитет НАТО, в состав которого входили ученые из разных стран и отраслей промышленности, организовал проведение дискуссий, посвящен- ных состоянию программной инженерии. Осенью 1967 года была сформирована исследовательская группа по компьютерным наукам. Цель этой группы заключа- лась в привлечении внимания к проблемам, связанным с программным обеспече- нием. Были приглашены 50 экспертов в разных областях, которые в составе трех рабочих групп сосредоточили внимание на разработке, производстве и поддержке программного обеспечения. При этом предпринимались попытки определить, описать и приступить к решению проблем в области программной инженерии.
В 1968 году на конференции НАТО, посвященной программной инженерии, были сформулированы ключевые проблемы программной инженерии, перечи- сленные в следующем перечне:
• определение и оценка степени успеха;
• создание сложных систем, требующих больших инвестиций, с непредска- зуемым внедрением;
• разработка систем в соответствии с графиком и спецификацией;
• оказание экономического давления на производителей, создающих опре- деленные продукты.
Благодаря идентификации этих проблем облегчается определение и формиро- вание областей деятельности для отрасли на ближайшие годы.

54
Часть I. Основы devops
Появление закрытого программного обеспечения
и стандартизация
До 1964 года существовала практика создания компьютеров, которые были весьма специфичными и соответствовали требованиям конкретного заказчика. Оборудо- вание и программное обеспечение были не стандартизованы и не взаимозаменяе- мы. В 1964 году компания IBM анонсировала семейство компьютеров System/360.
Компьютеры, входящие в это семейство, имели разные размеры и предназначались для использования в коммерческих и научных целях.
Благодаря созданию этого семейства компьютеров снизилась стоимость разработ- ки, производства и обслуживания, в то же время клиентам стало проще обновлять оборудование по мере необходимости. Семейство мэйнфреймов System/360 заня- ло господствующее положение, обеспечивая своим пользователям возможность начать с использования небольших вычислительных ресурсов, а потом наращи- вать их по мере необходимости. Эти компьютеры также обеспечивали гибкость в работе, позволяя отдельным сотрудникам изучать возможности оборудования и программного обеспечения. При этом они получали необходимые рабочие на- выки, которые могли успешно использовать в другом месте.
Вплоть до конца 1960-х годов компьютеры использовались на условиях аренды.
Это было связано с высокой ценой оборудования, программного обеспечения и со- путствующих услуг. Обычно предоставлялся исходный код для программного обеспечения, установленного на компьютере. После того как в 1969 году против аме- риканской компании IBM был подан антимонопольный иск, произошло разделение аппаратного и программного обеспечения и конкретных моделей компьютеров.
В результате стала возможной раздельная покупка оборудования (мэйнфреймов) и программного обеспечения. Это привело к изменению подхода к программному обеспечению, которое приобрело денежную стоимость, что, в свою очередь, привело к прекращению распространения открытого программного кода.
Сетевая эра
В 1979 году появилась всемирная система групп новостей Usenet, которую создали студенты из Университета Дьюка Том Трескотт и Джим Эллис. Изначально Usenet представляла собой простой сценарий оболочки, который автоматически вызывал разные компьютеры, искал изменения в файлах, находящихся на этих компью- терах, а потом копировал изменения с одного компьютера на другой с помощью набора программ UUCP. Этот набор обеспечивал передачу файлов и выполне- ние команд на удаленных компьютерах. Эллис выступил с докладом Invitation
to a General Access UNIX Network
1
в группе пользователей Unix, известной как
1
Ronda Hauben and Michael Hauben, Netizens: On the History and Impact of Usenet and the internet
(Los Alamitos, CA: IEEE, 1997).