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

332
Часть V. Масштабирование
Явно заданная культура
В государственном агентстве по оказанию цифровых услуг сформирова- ны следующие семь цифровых принципов (https://www.flickr.com/photos/
benterrett/7041509709):

цифровая форма (по умолчанию);

пользователи на первом плане;

обучение в путешествиях;

построение сети доверия;

выход за барьеры;

создание среды, способствующей процветанию технологических лидеров;

не делать все самому (это просто невозможно).
Работайте с пользователями так, как будто собираетесь формировать кабинет министров, а не обычную технологическую фирму.
— Дженнифер Палка. Code for America Summit
Как видите, в этих принципах явно присутствуют ценности и запреты. Напри- мер, фраза «пользователи на первом плане» представляет собой ценность, утвер- ждающую высший приоритет для пользователей. Если, например, инженер хочет поэкспериментировать и изучить новый инструмент или архитектуру, тогда в игру вступает запрет «не делать все самому (это просто невозможно)». Важно отметить, что позитивные ценности преобладают над негативными запретами, хотя всегда проще сказать людям, что им не стоит делать. Имейте в виду, что описание желаемых поведений намного эффективнее при создании желаемой культуры или атмосферы.
Помимо описанных семи цифровых принципов агентство GDS также внедрило следующие десять принципов дизайна (https://www.gov.uk/design-principles):

начните с выяснения потребностей;

делайте меньше;

проектируйте вместе с данными;

облегчайте тяжелую работу;

повторите, затем повторите еще раз;

это предназначено для всех;

поймите контекст;

Глава 14. Масштабирование: критические точки
333

создавайте цифровые сервисы, а не сайты;

будьте последовательны, но не однообразны;

создавайте открытый код, он всегда лучше.
Эти принципы проектирования отражаются в одном из указанных ранее циф- ровых принципов: пользователи на первом плане. В данном случае выделяются все аспекты пользовательского опыта, а не только, например, умение создавать серверный код. Критически важной для культуры является идея, суть которой заключается в том, что преобразование заключается не только в аппаратной и про- граммной технологии. На самом деле преобразование — это изменение опыта пользователей. В качестве примера можно рассмотреть внедрение цифровой услуги Claim Carer’s Allowance (https://gds.blog.gov.uk/2014/07/03/what-we-mean-
when-we-say-service-transformation/).
Создание явной культуры вместо полагания на неявное понимание, которое часто приводит к недоразумениям, позволило агентству GDS четко сосредото- читься на определенных типах изменений, которые оно должно внести в своей сфере деятельности.
Планирование
Планирование — это важная часть любого процесса разработки программы либо предоставления цифровой услуги уполномоченной организацией. Путем явного оглашения целей и необходимого для их достижения времени, а также с помощью расстановки приоритетов для данного периода времени команды могут значитель- но увеличить вероятность достижения цели. Процесс планирования тесно связан с культурой явных определений. Если вы не сможете достаточно хорошо опреде- лить цели, чтобы запланировать их, вряд ли вы достигнете этих целей.
Процесс планирования изменений, осуществляемый командой GDS, включает выделение достаточного количества времени на исследование возможных реше- ний. Чтобы выбрать решение, наилучшим образом удовлетворяющее текущие потребности, производится оценка предлагаемых решений. При этом соблю- даются вышеизложенные цифровые принципы и принципы проектирования.
Также поддерживается общение с другими правительственными командами, позволяющее скоординировать усилия и удостовериться в том, что запланиро- ванная работа не выполняется в данный момент другой командой. Этот простой, но критически важный шаг позволит избежать пустых трат времени на дубли- рование работы.
Как только завершается сбор данных по проекту и требований к проекту, про- изводится оценка потенциальных решений, реализованных в форме открытого

334
Часть V. Масштабирование и коммерческого кода. Затем создается прототип, который совместно использует- ся командами, такими как разработчики, эксплуатационники и сервисные менед- жеры. Благодаря этому возможно получение обратной связи от максимального числа заинтересованных сторон прежде, чем полностью утвердить выбранное решение. Также минимизируются впустую потраченные усилия, если выясняется изменение направления разработки, и обеспечивается максимальное удовлетво- рение потребностей каждого заказчика, которому предлагаются потенциальные решения.
При планировании проектов или других работ в организации, особенно ра- ботающей в условиях масштабирования, обращайте внимание на следующие моменты.
t
Работают ли в этой области другие команды или группы?
t
Каким образом могут координироваться или объединяться усилия с дру- гими командами?
t
Какие заинтересованные стороны и лица, принимающие решения, должны быть привлечены?
t
Каким образом вы определяете успех для этого проекта?
Вызовы
Один из вызовов, который часто возникает в правительственных агентствах, — дублирование усилий разными группами (рис. 14.3). В каждой группе должны поддерживаться основные элементы инфраструктуры. Эти элементы применяют- ся дополнительно к работе, которая находится в центре внимания или в области компетенции определенной группы. Поскольку эти основные услуги не центра- лизованы, каждой команде или группе придется потратить время, чтобы нанять специалистов, обладающих необходимыми навыками.
Предоставление услуг на основе платформы многоарендной архитектуры в пра- вительственном секторе позволило бы сэкономить время эксплуатационных команд. Экономия достигается за счет того, что вводится централизованная служба поддержки, которая удовлетворяет всем требованиям безопасности и конфиденциальности. Централизованное предоставление услуг позволило бы сервисным командам сосредоточиться на областях, навыках и требованиях, ко- торые являются для них уникальными. Ключевые требования для мультиаренд- ной платформы, используемой в правительственных учреждениях, приведены в следующем списке:

она должна быть самообслуживаемой;

должны использоваться несколько провайдеров услуг;

должна быть изоляция кода, данных и логов.

Глава 14. Масштабирование: критические точки
335
Рис. 14.3. Дублирование услуг, предоставляемых правительственными организациями
Благодаря самообслуживанию пользователи получают полный контроль над нужными аспектами приложения. Это позволяет командам сосредоточиваться на разработке усовершенствований платформы, а не на создании услуг. В результате поощряется специализация, приводящая к формированию платформенных и сер- висных команд.
Второе требование, заключающееся в использовании нескольких провайдеров услуг, предотвращает привязку к одному поставщику, стимулирует конкурентное ценообразование и способствует устранению единственных точек отказа. В про- цессе обдумывания требований проекта лучше использовать несколько облачных хранилищ, чем одно. Заблаговременное соблюдение этого требования позволит отказаться от использования специфичных для поставщика средств, привязка к которым затруднит переход к другому провайдеру либо включение дополнитель- ных провайдеров в дальнейшем. Позднее в агентстве GPS решили отказаться от этого требования, поскольку решения с открытым исходным кодом также будут обеспечивать необходимую степень гибкости.
Третье, и наиболее существенное, требование для многоабонентской платформы заключается в полной изоляции кода, данных и логов между агентствами. Это необходимо, чтобы убедиться в том, что каждая группа или агентство в состоянии соблюдать собственные ограничения безопасности и конфиденциальности. Даже

336
Часть V. Масштабирование если одно из ограничений не удовлетворяется, платформа не может использовать- ся и, соответственно, не может рассматриваться как успешная. И хотя детали этого вызова являются уникальными для каждой правительственной организации, во многих организациях также должны удовлетворяться разные юридические тре- бования (например, соблюдение совместимости с PCI, SOX либо HIPAA). Все эти моменты должны учитываться в процессе планирования, чтобы избежать потен- циальных напрасных затрат усилий.
Формирование близости
Один из способов формирования близости, применяемых в GDS, заключается в участии в турнирах Global GovJams. Турнир GovJam (http://www.govjam.org/) подобен хакатону в том, что участники имеют ограниченное количество времени
(всего лишь 48 часов), чтобы завершить выбранные ими проекты. Вдохновленные идеями Global Service Jams и Sustainability Jams, организаторы турниров GovJam предлагают участникам свободно выбирать темы, голосовать за идеи и создавать команды.
Как только команды будут сформированы, они начнут общаться с клиентами, что- бы выяснить их нужды. В отличие от традиционного хакатона, в GovJam во главу угла ставится налаживание взаимодействия между людьми, заинтересованными во внедрении улучшений и инноваций. В сети Global GovJam объединяются и со- единяются люди со всего мира на основе общей темы и общей централизованной платформы, используемой для размещения прототипов. Также участники могут сотрудничать и обмениваться информацией с помощью Twitter, используя хэштег
#ggovjam
Затем в течение 48 часов команды создают прототипы. При этом используется все, что доступно, и все, что может применяться в работе, а также коллективный опыт и экспертные знания. Они регулярно просматривают демоверсии и видят, как другие пользователи испытывают и используют продукт, улучшая его на основе полученных знаний. Благодаря распространению идей и помощи между командами больше выигрывают клиенты, а не сами участники команд. Благодаря концентрации на сотрудничестве обеспечивается отличный способ внедрения совместного мышления в GDS.
Второй способ, используемый GDS для формирования близости, заключается в регулярном ведении блогов для обмена информацией об организации, ее целях и текущих проектах. Несмотря на необходимость соблюдения различных инструк- ций по безопасности и конфиденциальности, сотрудникам GDS рекомендуется публиковать посты в публичном блоге группы. Эти посты посвящены самым раз- ным темам, начиная от новых продуктов и услуг, которые доступны клиентам, и завершая способами усовершенствования культуры и процессов. В результате формируется узнаваемый образ группы и приобретаются привычки по получению знаний и обмену информацией.

Глава 14. Масштабирование: критические точки
337
И наконец, в GDS формируется близость на основе участия в сообществе разра- ботчиков ПО с открытым исходным кодом. Портал GOV.UK основан на исполь- зовании программного обеспечения с открытым исходным кодом. Благодаря использованию открытого исходного кода облегчается сосредоточение на нуждах пользователей. Этот код доступен на сайтах по адресам https://github.com/gds-
operations и https://github.com/alphagov.
Джеймс Стюарт (James Stewart), директор по технической архитектуре в агентстве
GDS, продемонстрировал общий подход к выбору инструмента, показанного на рис. 14.4, процитировав мирового судью Рангасвами.
Для устранения общих проблем используйте инструменты с открытым исход- ным кодом.
Для устранения редких проблем используйте платные решения.
Для устранения уникальных проблем создавайте свой код.
Рис. 14.4. Пирамида создания, покупки и использования открытого кода

338
Часть V. Масштабирование
По сути, эта цитата говорит нам, что все участники команды должны решать по- вседневные проблемы с помощью открытого исходного кода, внося свой вклад в сообщество. Вклад в сообщество подразумевает нечто большее, чем обычное подтверждение кода и включение таких элементов, как документация, отчеты об ошибках и иллюстрации. В случае возникновения редких проблем приобретите продукты, которые способствуют устранению этих проблем. И наконец, для устранения уникальных проблем, специфичных для вашей команды или орга- низации, создайте свое собственное решение.
В общем случае правительственное агентство по оказанию цифровых услуг рабо- тает над созданием и поддержкой явно определенной культуры, которая нацелена на пользователей и на решение связанных с пользователями проблем. К ценно- стям также относятся опыт проектирования и общий опыт, сосредоточение на использовании agile-практик для уменьшения количества затрат, ускоренного выполнения итераций, а также упрощения оказания цифровых и технологических услуг для других правительственных организаций. Акцент на сотрудничестве и близости, а также собственных ценностях и запретах появился в результате длинного пути к созданию культуры правительственных организаций, необходи- мой для успешности в будущем.
Практика: Target
За последние десять лет произошли серьезные изменения в том, как, где и когда люди совершают покупки. Клиенты компании Target должны легко получать до- ступ к услугам в любом месте и в любое время. Технология, заложенная в основе компании, критически важна для способности быстро модифицировать стратегии в соответствии с изменяющейся средой для цепочки поставок и в соответствии с требованиями клиента.
Поскольку размеры компании Target довольно большие, принятие devops-куль- туры не было односторонним, спущенным сверху вниз решением. Некоторые команды начали свое devops-путешествие отдельно, а после того, как полученные результаты доказали успешность выбранных стратегий, объединились. Инфор- мация для этого примера была подобрана на основе сообщений в блоге, общедо- ступных презентаций, опубликованных сотрудниками Target, и регистрационных документов компании.
Знакомство с Target
Компания Target Corporation — это розничная торговая компания со штаб-квар- тирой в Миннеаполисе, штат Миннесота. Основанная в 1902 году Джорджем
Дейтоном (George Dayton) как Dayton Dry Goods, в середине 2015 года Target

Глава 14. Масштабирование: критические точки
339
насчитывала примерно 347 тысяч сотрудников. По состоянию на 2015 год эта компания являлась вторым по величине импортером в США. Компания Target имеет сеть обычных магазинов, а также работает в банковском, фармацевтическом секторах и в сфере охраны здоровья.
Как любая современная компания, работающая в сфере розничных продаж, Target имеет большой послужной список технических инноваций. В 1988 году компания установила сканеры UPC во всех магазинах и центрах дистрибуции Target. Также был изменен дизайн магазинов, в частности появились более удобные товарные полки. Также в течение нескольких лет в магазинах появился ряд новых инно- ваций, от пунктов проверки цен, контрольно-кассовых аппаратов, карманных устройств проверки запасов товара на складах, пунктов формирования списков подарков до приложений, гарантирующих поставку товаров из центров дистрибу- ции в нужное время и место, а также другие инновации.
Начнем с желаемых результатов
В крупной организации с длинной историей путешествие в направлении измене- ний часто напоминает перемещение в запутанном лабиринте, состоящем из боль- шого числа изгибов и поворотов. Хорошее прохождение лабиринта включает луч- шие практики, которые минимизируют риск. Организация отражает сложность, создаваемую со временем. Если посмотреть на Target «с высоты птичьего полета», вряд ли вы определите начало devops-путешествия компании Target.
В действительности не было никакой единственной начальной точки. Многие команды начинали с разных начальных точек. Хизер Микман (Heather Mickman) возглавила команду под названием «API and Integration Development», а Росс
Клэнтон (Ross Clanton) — команду «Ops Infrastructure Services». Именно эти две команды работали над внедрением devops в организации. Избранные командами способы не относятся к категории простых, причем некоторые сотрудники даже не знали о наличии термина devops. Вместо этого они описывали желаемые резуль- таты на обычном языке, например «более скудно, более быстро, предоставление более качественных услуг». Эти слова выражают суть философии devops. Как объясняет Хизер Микман:
Я должна была прекратить использовать термин devops, поскольку он перегружен смыслом, несет большое количество дезинформации и не- доразумений. Я беседовала с коллегами и руководителями организации и видела, как они умолкали, когда я произносила слово «devops».
Решение Микман в пользу отказа от использования термина devops в силу его пе- регруженности смыслом демонстрирует силу народных моделей, рассмотренных в главе 2. Вы могли бы столкнуться с подобными реакциями в своих собствен- ных организациях, когда предвзято настроенные люди проявляют недовольство