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

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

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. Вы могли бы столкнуться с подобными реакциями в своих собствен- ных организациях, когда предвзято настроенные люди проявляют недовольство
Источник: https://files.student-it.ru/previewfile/170498