50 | 
Вступление
78 |
79 | Основная цель DevOps в любой организации - улучшить качество поставки ценности клиентам и бизнесу, а не уменьшить расходы, улучшить автоматизацию или внедрить систему управления конфигурацией. Следовательно для эффективного взаимодействия разработки (Dev) и эксплуатации (Ops) в разных организациях нужны разные структуры команд.
80 |Резюме
87 | 88 |Какая именно структура DevOps команды подойдет организации зависит от нескольких факторов:
Набор продуктов организации: чем меньше програмнных продуктов, тем проще взаимодействие, вследствие меньшего количества естественных барьеров описанных законом Конвея.
95 |Степень, качество и эффективность технического управления; имеют ли разработка и эксплуатация общие цели.
100 |Готовность и желание организации изменить отдел эксплуатации в соответствии со своим потоком создания ценностей, и готовность продуктовых команд относиться серьезно к эксплуатационным особенностям.
105 |Наличие в организации способности и навыков взять инициативу в вопросах эксплуатации.
110 |Конечно, существуют различные вариации решений в поднятой проблематике; структуры и паттерны приведены как примеры и справочный материал для оценки применимости тех или иных шаблонов. На практике, чаще всего лучшим решением является комбинация нескольких шаблонов или шаблон меняющийся в другой.
116 |Так какая структура команды нужна для процветания DevOps? Очевидно, что не существует серебряной пули или структуры команды, которая подошла бы любой организации. Тем не менее, будет полезно описать несколько различных моделей построения команд, некоторые из них подойдут конкретной организации лучше остальных. Изучая сильные и слабые стороны структур команд (или топологий), можно найти такую структуру, которая наилучшим образом подойдет для реализации DevOps практик в вашей организации, учитывая закон Конвея.
124 |Большинство DevOps топологий уже были ранее описаны. В частности, Lawrence Sweeney из CollabNet описывает интересные подробности в комментариях к публикации в блоге Ben Kepes о структурах, которые я обозначил как Антипаттерн B (Изолированная DevOps команда), Паттерн 3 (Эксплуатация как IaaS), и Паттерн 1 (Сотрудничество разработки и эксплуатации). У DevOpsGuys есть список из двенадцати антипаттернов DevOps, и у Jez Humble, Gene Kim, Damon Edwards (и многих других) есть подобные списки. Я добавил три дополнительные 'топологии', которые я редко встречал (Общая эксплуатация, DevOps-as-a-Service и Временная DevOps команда).
128 |DevOps Anti-Types
138 | 139 |It’s useful to look at some bad practices, what 141 | we might call ‘anti-types’ (after the ubiquitous ‘anti-pattern‘).
142 |-
149 |
150 |
- A: Dev vs Ops 151 |
- B: DevOps Silo 152 |
- C: No Ops Needed 153 |
- D: Tools Team 154 |
- E: SysAdmin 155 |
- F: Embedded Ops 156 |
- G: Dev vs DBA 157 |
Anti-Type A: Dev and Ops Silos
166 | 167 |This is the classic ‘throw it over the wall’ split between Dev and Ops. It means that story points can be claimed early (DONE means ‘feature-complete’, but not working in Production), and software operability suffers because Devs do not have enough context for operational features and Ops folks do not have time or inclination to engage Devs in order to fix the problems before the software goes live.
168 | 169 |We likely all know this topology is bad, but I think there are actually worse topologies; at least with Anti-Type A (Dev and Ops Silos), we know there is a problem.
170 |
175 | 
182 | Anti-Type B: DevOps Team Silo
186 | 187 |The DevOps Team Silo (Anti-Type B) typically results from a manager or exec deciding that they “need a bit of this DevOps thing” and starting a ‘DevOps team’ (probably full of people known as ‘a DevOp‘). The members of the DevOps team quickly form another silo, keeping Dev and Ops further apart than ever as they defend their corner, skills, and toolset from the ‘clueless Devs’ and ‘dinosaur Ops’ people.
188 | 189 |The only situation where a separate DevOps silo really makes sense is when the team is temporary, lasting less than (say) 12 or 18 months, with the express purpose of bringing Dev and Ops closer together, and with a clear mandate to make the DevOps team superfluous after that time; this becomes what I have called a Type 5 DevOps Topology.
190 |Anti-Type C: Dev Don't Need Ops
201 | 202 |This topology is borne of a combination of naivety and arrogance from developers and development managers, particularly when starting on new projects or systems. Assuming that Ops is now a thing of the past (“we have the Cloud now, right?”), the developers wildly underestimate the complexity and importance of operational skills and activities, and believe that they can do without them, or just cover them in spare hours.
203 | 204 |Such an Anti-Type C DevOps topology will probably end up needing either a Type 3 (Ops as IaaS) or a Type 4 (DevOps-as-a-Service) topology when their software becomes more involved and operational activities start to swamp ‘development’ (aka coding) time. If only such teams recognised the importance of Operations as a discipline as important and valuable as software development, they would be able to avoid much pain and unnecessary (and quite basic) operational mistakes.
205 |
210 | 
217 | Anti-Type D: DevOps as Tools Team
221 | 222 |In order to "become DevOps" without losing current dev teams velocity (read delivery of functional stories), a DevOps team is set up to work on the tooling required for deployment pipelines, configuration management, environment management, etc. Meanwhile Ops folks continue to work in isolation and Dev teams continue to throw them applications "over the wall".
223 | 224 |Although the outcomes of this dedicated team can be beneficial in terms of an improved tool chain, its impact is limited. The fundamental problem of lack of early Ops involvement and collaboration in the application development lifecycle remains unchanged.
225 |Антипаттерн E: Переименованные сисадмины
236 | 237 |Этот типичный антипаттерн для организаций с низкой инженерной зрелостью. Они хотят улучшить свои практики и уменьшить стоимость, но они не видят IT как основной двигатель бизнеса. Поскольку успехи с DevOps в отрасли теперь очевидны, они тоже хотят “сделать DevOps”.
238 | 239 |DevOps становится всего лишь переименованием роли, уже известной ранее как системный администратор, без каких-либо культурных или организационных изменений. Этот антипаттерн становится все более и более распространенным из-за того, что недобросовестные рекрутеры начинают искать кандидатов с навыками автоматизации и инструментов. К сожалению, лишь их межличностные коммуникативные навыки могут сделать DevOps в компании процветающим.
240 |
245 | 
252 | Антипаттерн F: Эксплуатация встроенная в команду разработки
258 | 259 |Организация не хочет держать отдельную команду эксплуатации, поэтому команды разработки берут на себя ответственность за инфраструктуру, управление окружениями, мониторинг и т.д. Однако, делать это в рамках проекта или продукта, означает подвергнуть эти элементы ограничению ресурсов и изменению приоритетов, которые приведут к непостоянным и полузаконченным решениям.
260 | 261 |В этом антипаттерне организация демонстрирует недооценку важности и навыков, требуемых для эффективной IT эсплуатации.
262 |Антипаттерн G: Изоляция разработчиков и DBA
275 | 276 |Это форма Антипаттерна А (Изоляция разработки и эксплуатации), которая популярна в средних и крупных компаниях, где множество устаревших систем, зависящих от одного и того же набора данных. Эти базы данных настолько важны для бизнеса, что специализированная команда DBA, часто под зонтиком эксплуатации, отвечает за обслуживание, производительность и аварийное восстановление. Это можно понять. Проблема в том, что эта команда становится сторожем ворот от любых изменений базы данных, что, фактически, становится препятствием для небольших и частых поставок. (Основной принцип DevOps и непрерывной поставки).
277 | 278 |Кроме того, как и эксплуатация в Антипаттерне А, команда DBA не участвует в раннем этапе разработки приложения, поэтому проблемы с данными (миграция, производительность и т.д.) обнаруживаются в конце цикла поставки. В сочетании с перегруженностью от поддержки множества приложений и баз данных, в конечном итоге это приводит к постоянному пожаротушению и давлению на процесс поставки.
279 |
284 | DevOps структуры команд
295 |В противовес антипаттернам мы можем посмотреть на некоторые структуры, в которых DevOps может работать
297 |-
304 |
305 |
- 1: Dev+Ops 306 |
- 2: Shared Ops 307 |
- 3: Ops as IaaS 308 |
- 4: DevOps-as-a-Service 309 |
- 5: Temp DevOps Team 310 |
- 6: DevOps Evangelists 311 |
- 7: SRE Team 312 |
- 8: Container-Driven 313 |
- 9: DB Capability 314 |
Тип 1: Сотрудничество команд разработки и эксплуатации
323 |Это 'земля обетованная' культуры DevOps: комфортное сотрудничество между командами разработки и командами эксплуатации, каждая из которых специализируется на своем, но, по мере необходимости, там где нужно. При этом, вероятно, есть много отдельных команд разработки, каждая из которых работает над отдельным или частично отдельным продуктовым стеком.
324 | 325 |Я считаю, что модель 1-го Типа нуждается в достаточно существенных организационных изменениях для ее создания, а также в высокой степени компетентности в команде технического руководства. Разработка и эксплуатация должны иметь четко выраженную и очевидную полезную общую цель ('Доставка надежных, частых изменений' или что-то еще). Сотрудники команды эксплуатации должны уверенно сотрудничать с командой разработки, понимать и справляться с тестированием в разработке (test-driven), знать Git, а программисты должны серьезно относиться к эксплуатационным функциям и самостоятельно подключать сотрудников эксплуатации для реализации логгирования и так далее, везде где необходимо изменение культуры из недавнего прошлого.
326 | 327 |
332 | Применимость Тип 1: организации с сильным техническим руководством.
336 | Потенциальная эффективность: ВЫСОКАЯ
346 | Тип 2: Полностью распределенные функции эксплуатации
357 |Там, где команда эксплуатации была интегрирована в группу разработки продуктов, мы видим топологию Типа 2. Между задачами разработки и эксплуатации мало разделения и все сотрудники сфокусированы на общей цели. Это спорная форма Тип 1 (Сотрудничество команд разработки и эксплуатации), но она имеет свои возможности.
358 | 359 |Такие организации, как Netflix и Facebook, практически разрабатывающих один веб-продукт, реализовали эту топологию Типа 2, но я думаю, что это, вероятно, не очень удобно за пределами узкого целевого продукта, поскольку бюджетные ограничения и контекстное переключение обычно присутствуют в организации с несколькими цифровыми продуктами, что заставит их разделить разработку и эксплуатацию, скажем, обратно к модели Типа 1. Эта топология также может быть названа «NoOps», поскольку нет отдельной или видимой команды эксплуатации (хотя Netflix NoOps также может быть Типом 3 (Эксплуатация как IaaS)).
360 |Тип 3: Эксплуатация как Инфрраструктура-как-сервис (Infrastructure-as-a-Service, IaaS)
378 |Для организаций с довольно традиционным отделом ИТ эксплуатации, который не может или не будет быстро (достаточно быстро) изменяться, и для организаций, которые запускают все свои приложения в публичном облаке (Amazon EC2, Rackspace, Azure и т.д.), вероятно поможет рассматривать эксплуатацию как команду, которая просто обеспечивает гибкую инфраструктуру, на которой развертываются и запускаются приложения. Внутренняя команда эксплуатации, таким образом, прямо эквивалентна Amazon EC2 или Инфраструктура-как-сервис (Infrastructure-as-a-Service).
379 | 380 |Команда (возможно, виртуальная команда) разработки затем выступает в качестве источника знаний об эксплуатационных функциях, метриках, мониторинге, настройке серверов и т.д., и, вероятно, выполняет большую часть взаимодействия с командой IaaS. Тем не менее, эта команда по-прежнему является командой разработчиков, следует стандартным практикам, таким как TDD, CI, итеративное развитие, коучинг и т.д.
381 | 382 |Топология IaaS разменивается некоторой потенциальной эффективностью, теряя прямое сотрудничество с командой эксплуатации, для более легкой реализации, возможно, получая ценность быстрее, чем в случае Типа 1 (Сотрудничество команд разработки и эксплуатации), который можно попытаться воплотить позже.
383 |
388 | Применимость Тип 3: для организаций с несколькими различными продуктами и сервисами, с традиционным подразделением эксплуатации или чьи приложения полностью запускаются в публичном облаке.
392 | Потенциальная эффективность: СРЕДНЯЯ
402 | Type 4: DevOps as an External Service
413 | 414 |Some organisations, particularly smaller ones, might not have the finances, experience, or staff to take a lead on the operational aspects of the software they produce. The Dev team might then reach out to a service provider like Rackspace to help them build test environments and automate their infrastructure and monitoring, and advise them on the kinds of operational features to implement during the software development cycles.
415 | 416 |What might be called DevOps-as-a-Service could be a useful and pragmatic way for a small organisation or team to learn about automation, monitoring, and configuration management, and then perhaps move towards a Type 3 (Ops as IaaS) or even Type 1 (Dev and Ops Collaboration) model as they grow and take on more staff with operational focus.
417 |Type 5: DevOps Team with an Expiry Date
435 | 436 |The DevOps Team with an Expiry Date (Type 5) looks substantially like Anti-Type B (DevOps Team Silo), but its intent and longevity are quite different. This temporary team has a mission to bring Dev and Ops closer together, ideally towards a Type 1 (Dev and Ops Collaboration) or Type 2 (Fully Shared Ops Reponsibilities) model, and eventually make itself obsolete.
437 | 438 |The members of the temporary team will ‘translate’ between Dev-speak and Ops-speak, introducing crazy ideas like stand-ups and Kanban for Ops teams, and thinking about dirty details like load-balancers, management NICs, and SSL offloading for Dev teams. If enough people start to see the value of bringing Dev and Ops together, then the temporary team has a real chance of achieving its aim; crucially, long-term responsibility for deployments and production diagnostics should not be given to the temporary team, otherwise it is likely to become a DevOps Team Silo (Anti-Type B).
439 |
444 | Type 5 suitability: as a precursor to Type 1 topology, but beware the danger of Anti-Type B.
448 | Potential effectiveness: LOW to HIGH
458 | Type 6: DevOps Evangelists Team
471 | 472 |Within organisations that have a large gap between Dev and Ops (or the tendency towards a large gap), it can be effective to have a 'facilitating' DevOps team that keeps the Dev and Ops sides talking. This is a version of Type 5 (DevOps Team with an Expiry Date) but where the DevOps team exists on an ongoing basis with the specific remit of facilitating collaboration and cooperation between Dev and Ops teams. Members of this team are sometimes called 'DevOps Evangelists', because they help to spread awareness of DevOps practices.
473 | 474 | 478 |Type 7: SRE Team (Google Model)
498 | 499 |DevOps often recommends that Dev teams join the on-call rotation, but it's not essential. In fact, some organisations (including Google) run a different model, with an explicit 'hand-off' from Development to the team that runs the software, the Site Reliability Engineering (SRE) team. In this model, the Dev teams need to provide test evidence (logs, metrics, etc.) to the SRE team showing that their software is of a good enough standard to be supported by the SRE team.
500 | 501 |Crucially, the SRE team can reject software that is operationally substandard, asking the Developers to improve the code before it is put into Production. Collaboration between Dev and SRE happens around operational criteria but once the SRE team is happy with the code, they (and not the Dev team) support it in Production.
502 |
507 | Type 7 suitability: Type 7 is suitable only for organisations with a high degree of engineering and organisational maturity. Beware of a return to Anti-Type A if the SRE/Ops team is told to "JFDI" deploy.
513 | Potential effectiveness: LOW to HIGH
523 | Type 8: Container-Driven Collaboration
537 | 538 |Containers remove the need for some kinds of collaboration between Dev and Ops by encapsulating the deployment and runtime requirements of an app into a container. In this way, the container acts as a boundary on the responsibilities of both Dev and Ops. With a sound engineering culture, the Container-Driven Collaboration model works well, but if Dev starts to ignore operational considerations this model can revert towards to an adversarial 'us and them'.
539 |Type 9: Dev and DBA Collaboration
559 | 560 |In order to bridge the Dev-DBA chasm, some organisations have experimented with something like Type 9, where a database capability from the DBA team is complimented with a database capability (or specialism) from the Dev team. This seems to help to translate between the Dev-centric view of databases (as essentially dumb persistence stores for apps) and the DBA-centric view of databases (smart, rich sources of business value).
561 |
566 | Type 9 suitability: for organisations with one or more large, central databases with multiple connected applications.
570 | Potential effectiveness: MEDIUM