Хабрахабр

Непрерывная инфраструктура в облаке

Демонстрация использования инструментов с открытым исходным кодом, таких как Packer и Terraform, для непрерывной поставки изменений инфраструктуры в любимую пользователями облачную среду.

Материал подготовлен на основе выступления Пола Стека (Paul Stack) на нашей осенней конференции DevOops 2017. Пол — инфраструктурный разработчик, который раньше работал в HashiCorp и участвовал в разработке инструментов, используемых миллионами людей (например, Terraform). Он часто выступает на конференциях и доносит практику с переднего края внедрений CI/CD, принципы правильной организации operations-части и умеет доходчиво рассказать, зачем вообще админам этим заниматься. Далее в статье повествование ведется от первого лица.
Итак, начнем сразу с нескольких ключевых выводов.

Долгоработающие сервера — отстой

И такая компания не одна. Ранее я работал в организации, где мы развернули Windows Server 2003 еще в 2008 году, и сегодня они по-прежнему в продакшне. Это очень плохая идея, потому что серверы получаются нетиповые. Используя удаленный рабочий стол на этих серверах, на них устанавливают ПО вручную, загружая бинарные файлы из интернета. Вы не можете гарантировать, что в продакшене происходит то же самое, что и в вашей среде разработки, в промежуточной среде, в среде QA.

Неизменяемая инфраструктура

В 2013 году появилась статья в блоге Чада Фоилера «Выбросьте ваши серверы и сожгите код: неизменяемая инфраструктура и одноразовые компоненты» (Chad Foiler «Trash your servers and burn your code: immutable infrastructure and disposable components»). Это разговор по большей части о том, что неизменяемая инфраструктура — это путь вперед. Мы создали инфраструктуру, а если нам нужно ее изменить, мы создаем новую инфраструктуру. Такой подход очень распространен в облаке, потому что здесь это быстро и дешево. Если у вас есть физические центры обработки данных, это немного сложнее. Очевидно, если вы запускаете виртуализацию ЦОД, все становится проще. Однако, если вы все еще каждый раз запускаете физические серверы, для ввода нового требуется немного больше времени, чем для изменения существующего.

Одноразовая инфраструктура

По мнению функциональных программистов, «неизменяемая» — на самом деле неправильный термин для этого явления. Поскольку, чтобы быть действительно неизменяемой, вашей инфраструктуре нужна файловая система «только для чтения»: никакие файлы не будут записаны локально, никто не сможет использовать SSH или RDP и т.д. Таким образом, похоже, что на самом деле инфраструктура не является неизменяемой.

В итоге они пришли к согласию, что «одноразовая инфраструктура» — это более подходящая формулировка. Терминология обсуждалась в Twitter в течение шести или даже восьми дней несколькими людьми. Вам не нужно за нее держаться. Когда жизненный цикл «одноразовой инфраструктуры» заканчивается, ее можно легко уничтожить.

Коров на фермах обычно не рассматривают как домашних питомцев. Приведу аналогию.

У каждой особи есть номер и бирка. Когда у вас на ферме есть крупный рогатый скот, вы не даете ему индивидуальные имена. Если у вас в продакшне все еще есть серверы, созданные вручную в 2006 году, они имеют значимые имена, например «база данных SQL на продакшне 01». Так же и с серверами. И если один из серверов падает, начинается ад. И у них очень специфический смысл.

Это и есть «одноразовая инфраструктура». Если одно из животных стада умирает, фермер просто покупает новое.

Непрерывная поставка

Итак, как это объединить с непрерывной поставкой (Continuous Delivery)?
Все, о чем я сейчас рассказываю, существует довольно давно. Я лишь пытаюсь совместить идеи развития инфраструктуры и разработки программного обеспечения.

Например, Мартин Фаулер (Martin Fowler) писал о непрерывной интеграции в своем блоге еще в начале 2000-х годов. Разработчики ПО в течение долгого времени практикуют непрерывную поставку и непрерывную интеграцию. Джез Хамбл (Jez Humble) долгое время продвигал непрерывную поставку.

Есть стандартное определение из «Википедии»: непрерывная поставка — это набор практик и принципов, направленных на создание, тестирование и выпуск программного обеспечения максимально быстро. Если вы присмотритесь внимательнее, здесь нет ничего созданного специально для исходного кода ПО.

Для создания работающего программного обеспечения требуется много кусочков головоломки. Определение не говорит о веб-приложениях или API, это о программном обеспечении в целом. Таким образом вы можете точно так же практиковать непрерывную поставку для кода инфраструктуры.

И люди, которые пишут код приложений, также пишут код инфраструктуры (и наоборот). Разработка инфраструктуры и приложений — довольно близкие направления. Больше нет такого разделения и специфических ловушек каждого из миров. Эти миры начинают объединяться.

Принципы и практики непрерывной поставки

Непрерывная поставка имеет ряд принципов:

  • Процесс выпуска / развертывания программного обеспечения должен быть повторяемым и надежным.
  • Автоматизируйте все!
  • Если какая-то процедура сложна или болезненна, выполняйте ее чаще.
  • Держите все в системе управления версиями.
  • Сделано — значит «зарелизено».
  • Интегрируйте работу с качеством!
  • Каждый несет ответственность за процесс выпуска.
  • Повышайте непрерывность.

Но гораздо важнее, что непрерывная поставка имеет четыре практики. Возьмите их и перенесите непосредственно в инфраструктуру:

  • Создавайте бинарные файлы только один раз. Создайте свой сервер один раз. Здесь речь об «одноразовости» с самого начала.
  • Используйте одинаковый механизм развертывания в каждой среде. Не практикуйте разный деплой в разработке и на продакшне. Вы должны использовать один и тот же путь в каждой среде. Это очень важно.
  • Протестируйте ваш деплой. Я создал много приложений. Я создавал множество проблем, потому что не следил за механизмом деплоя. Всегда надо проверять, что происходит. И я не говорю, что вы должны потратить пять или шесть часов на масштабное тестирование. Достаточно «дымового теста». У вас есть ключевая часть системы, которая, как вы знаете, позволяет вам и вашей компании зарабатывать деньги. Не поленитесь запустить тестирование. Если вы этого не сделаете, могут возникнуть перебои, которые будут стоить вашей компании денег.
  • И наконец, самое главное. Если что-то сломалось, остановитесь и исправьте это немедленно! Вы не можете допустить, чтобы проблема росла и становилась все хуже и хуже. Вы должны это исправить. Это действительно важно.

Кто-нибудь читал книгу «Continuous delivery»?

Я не говорю, что вы должны сесть и потратить выходной день на ее прочтение. Я уверен, ваши компании оплатят вам экземпляр, который вы сможете передавать внутри команды. Но я рекомендую периодически осваивать небольшие кусочки книги, переваривать их и думать о том, как перенести это на свою среду, в свою культуру и в свой процесс. Если вы это сделаете, вероятно, вы захотите уйти из ИТ. Потому что непрерывная поставка — это разговор о постоянном улучшении. Один маленький кусочек за раз. Это занимает много времени, вызывает много протестов, поскольку по мере внедрения меняется культура. Это не просто сесть в офисе вместе с коллегами и боссом и начать разговор с вопроса: «Как мы будем внедрять непрерывную поставку?», потом написать 10 вещей на доске и через 10 дней понять, что вы ее реализовали.

Дальнейший рассказ будет о том, почему мы должны использовать Terraform и как интегрировать его в свою среду. Сегодня мы будем использовать два инструмента: Terraform и Packer (оба — разработки Hashicorp). До недавнего времени я также работал в Hashicorp. Я не случайно говорю об этих двух инструментах. Но даже после того как я покинул Hashicorp, я все еще вношу вклад в код этих инструментов, потому что на самом деле считаю их очень полезными.

Провайдеры — это облака, Saas-сервисы и т.п. Terraform поддерживает взаимодействие с провайдерами.

д. Внутри каждого поставщика облачных услуг есть несколько ресурсов, например подсеть, VPC, балансировщик нагрузки и т. С помощью DSL (предметно-ориентированный язык, domain-specific language) вы указываете Terraform, как будет выглядеть ваша инфраструктура.

Terraform использует теорию графов.

Узлы — это части нашей инфраструктуры, например балансировщик нагрузки, подсеть или VPC. Вероятно, вы знаете теорию графов. Это все, что я лично считаю необходимым знать о теории графов для использования Terraform. Ребра — это отношения между этими системами. Остальное оставим экспертам.

И B должен быть создан до C (инстанс), потому что есть предписанный порядок создания абстракций в Amazon или любом другом облаке.
Более подробная информация по этой теме есть в YouTube Пола Хензе (Paul Hinze), который все еще работает в Hashicorp директором по инфраструктуре. Terraform на самом деле использует направленный граф, потому что он знает не только взаимоотношения, но и их порядок: что A (предположим, что A — VPC) должен быть установлен до B, который является подсетью. По ссылке — прекрасная беседа об инфраструктуре и теории графов.

Практика

Напишем код, это гораздо лучше, чем обсуждать теорию.

Для их создания я использую Packer и собираюсь показать вам, как это делается. Ранее я создал AMI (Amazon Machine Images).

п.) и создается из образа. AMI — это экземпляр виртуального сервера в Amazon, он предопределен (в плане конфигурации, приложений и т. По сути, AMI — это мои контейнеры Docker. Мне нравится, что я могу создать новые AMI.

Отправившись в интерфейс Amazon, мы видим, что у нас есть всего один AMI и ничего больше: Итак, у меня есть AMI, у них есть ID.

Все очень просто. Я могу показать вам, что находится в этом AMI.

У меня есть шаблон JSON-файла:

, "builders": [{ "type": "amazon-ebs", "region": "{{user ‘region’}}", "source_ami": "{{user ‘source_ami’}}", "ssh_pty": true, "instance_type": "t2.micro", "ssh_username": "ubuntu", "ssh_timeout": "5m", "associate_public_ip_address": true, "ami_virtualization_type": "hvm", "ami_name": "application_instance-{{isotime \"2006-01-02-1504\"}}", "tags": { "Version": "{{user ‘version’}}" } }], "provisioners": [ { "type": "shell", "start_retry_timeout": "10m", "inline": [ "sudo apt-get update -y", "sudo apt-get install -y ntp nginx"
]
},
{ "type": "file", "source": "application-files/nginx.conf", "destination": "/tmp/nginx.conf"
},
{ "type": "file", "source": "application-files/index.html", "destination": "/tmp/index.html"
},
{ "type": "shell", "start_retry_timeout": "5m", "inline": [ "sudo mkdir -p /usr/share/nginx/html", "sudo mv /tmp/index.html /usr/share/nginx/html/index.html", "sudo mv /tmp/nginx.conf /etc/nginx/nginx.conf", "sudo systemctl enable nginx.service" ]
}
]
}

У нас есть переменные, которые мы передаем, а у Packer есть список так называемых Builders для разных областей; их множество. Builder использует специальный источник AMI, который я передаю в AMI-идентификаторе. Я даю ему имя пользователя и пароль SSH, а также указываю, нужен ли ему публичный IP-адрес, чтобы люди могли получить к нему доступ извне. В нашем случае это не имеет особого значения, потому что это инстанс AWS для Packer.
Также мы задаем имя AMI и теги.

Он здесь только для того, чтобы показать вам, как он работает. Вам необязательно разбирать этот код. Она станет актуальной позже, когда мы войдем в Terraform. Самая важная часть здесь — это версия.

Я фактически устанавливаю NCP и nginx, чтобы показать вам, что я могу здесь сделать. После того как builder вызывает инстанс, на нем запускаются провизионеры. Все очень просто. Я копирую некоторые файлы и просто настраиваю конфигурацию nginx. Затем активирую nginx, чтобы он стартовал при запуске инстанса.

Я могу его использовать в будущем. Итак, у меня есть сервер приложений, и он работает. Потому что это JSON-конфигурация, где вы можете столкнуться с некоторыми проблемами.
Чтобы это сделать, я запускаю команду: Однако я всегда проверяю свои шаблоны Packer.

make validate

Получаю ответ, что шаблон Packer проверен успешно:

Фактически это будет процесс: если разработчик изменит шаблон, будет сформирован pull request, инструмент CI проверит запрос, выполнит эквивалент проверки шаблона и опубликует шаблон в случае успешной проверки. Это всего лишь команда, поэтому я могу подключить ее к инструменту CI (любому). Все это можно объединить в «Мастер».
Получаем поток для шаблонов AMI — нужно просто поднять версию.

Предположим, что разработчик создал новую версию AMI.

0. Я просто поправлю версию в файлах с 1. 0. 0 на 1. 1, чтобы показать вам разницу:

<html>
<head> <tittle>Welcome to DevOops!</tittle>
</head>
<body>
<h1>Welcome!</h1>
<p>Welcome to DevOops!</p>
<p>Version: 1.0.1</p>
</body>
</html>

Вернусь в командную строку и запущу создание AMI.
Я не люблю запускать одни и те же команды. Мне нравится создавать AMI быстро, поэтому я использую make-файлы. Давайте заглянем при помощи cat в мой make-файл:

cat Makefile

Я даже предусмотрел Help: я набираю make и нажимаю табуляцию, и он мне показывает все target. Это мой make-файл.

0. Итак, мы собираемся создать новый AMI версии 1. 1.

make ami

Вернемся к Terraform.

Это демонстрация. Акцентирую внимание, что это не код с продакшена. Есть способы сделать то же самое лучше.

Поскольку я больше не работаю на Hashicorp, поэтому могу высказать свое мнение про модули. Я везде использую модули Terraform. Например, мне нравится инкапсулировать все, что связано с VPC: сети, подсети, таблицы маршрутизации и т. Для меня модули находятся на уровне инкапсуляции. п.

Разработчики, которые с этим работают, могут не заботиться об этом. Что происходит внутри? Но совершенно не обязательно вникать в детали. Им нужно иметь общие представления о том, как работает облако, что такое VPC. Только люди, которым действительно нужно изменить модуль, должны в нем разбираться.


Что тут происходит? Здесь я собираюсь создать AWS resource и модуль VPC. Далее берется список acailability_zones. Берется cidr_block верхнего уровня и создаются три частные подсети и три публичные подсети. Но мы не знаем, что это за зоны доступности.

Только не используйте этот модуль VPN. Мы собираемся создать VPN. Он использует только публичный IP-адрес и упомянут здесь лишь для того, чтобы показать вам, что мы можем подключиться к VPN. Это openVPN, который создает один инстанс AWS, не имеющий сертификата. Мне потребовалось около 20 минут и два пива, чтобы написать собственный. Существуют более удобные инструменты для создания VPN.



Некоторая конфигурация запуска основана на AMI-ID, и она объединяет несколько подсетей и зон доступности, а также использует SSH-ключ.
Вернемся к этому через секунду. Затем мы создаем application_tier, который является auto scaling group — балансировщиком нагрузки.

Они отличаются для разных учетных записей AWS. Ранее я уже упоминал зоны доступности. Ваша учетная запись AWS может иметь доступ к B, C и E. Моя учетная запись в США на Востоке может иметь доступ к зонам A, B и D. Мы в Hashicorp предположили, что можем создать такие источники данных, чтобы можно было запросить у Amazon, что именно доступно для нас. Таким образом, фиксируя эти значения в коде, мы будем сталкиваться с проблемами. Благодаря этому мы можем использовать источники данных для AMI. Под капотом мы запрашиваем описание зон доступности, а затем возвращаем список всех зон для вашей учетной записи.

Я создал auto scaling group, в которой запущены три инстанса. Теперь мы добрались до сути моей демонстрации. 0. По умолчанию все они имеют версию 1. 0.

д. Когда мы задеплоим новую версию AMI, я снова запущу конфигурацию Terraform, это изменит конфигурацию запуска, и новый сервис получит следующую версию кода и т. И мы можем этим управлять.

Мы видим, что работа Packer закончена и у нас есть новый AMI.
Я возвращаюсь к Amazon, обновляю страницу и вижу второй AMI.

Вернемся к Terraform.

10 Terraform разбил провайдеров по отдельным репозиториям. Начиная с версии 0. И команда init terraform получает копию провайдера, который нужен для запуска.

Мы готовы двигаться вперед.
Далее мы должны выполнить terraform get — загрузить необходимые модули. Провайдеры загружены. Так что Terraform получит все модули на локальном уровне. Они сейчас находятся на моей локальной машине. Именно поэтому я говорил о модуле VPC. Вообще модули могут храниться в их собственных репозиториях на GitHub или где-то еще. И это API для команды разработчиков для совместной работы с ними. Вы можете дать команде сетевиков доступ для внесения изменений. Действительно полезно.

Следующим шагом мы хотим построить граф.

Начнем с

terraform plan

В нашем случае он создаст 35 новых ресурсов. Terraform возьмет текущее локальное состояние и сравнит с учетной записью AWS, указав различия.

Теперь мы применим изменения:

terraform apply

Это просто команды, передача переменных в Terraform. Вам необязательно делать все это с локальной машины. Я бы хотел, чтобы все, кто когда-либо использует Terraform, работали с удаленным состоянием. Вы можете перенести этот процесс в инструменты CI.
Если вы хотите переместить это в CI, вы должны использовать удаленное состояние. Пожалуйста, не используйте локальное состояние.

Например, если вы создаете инстанс AWS, вам нужно предоставить ему пароль, и он может сохранить его в вашем состоянии. Один из моих приятелей отметил, что даже после всех лет работы с Terraform он все еще открывает для себя что-то новое. Поэтому не старайтесь хранить все локально. Когда я работал в Hashicorp, мы предполагали, что будет совместный процесс, который изменяет этот пароль. И тогда вы сможете поместить все это в инструменты CI.

Итак, инфраструктура для меня создана.

Terraform может построить граф:

terraform graph

Фактически он и вам дает возможность оценить, что происходит в вашей инфраструктуре. Как я сказал, он строит дерево. Поскольку связи имеют направления, мы говорим о направленном графе. Он покажет вам отношения между всеми разными частями — все узлы и ребра.

Граф будет представлять собой JSON-список, который можно сохранить в PNG- или DOC-файле.

У нас действительно создается auto scaling group. Вернемся в Terraform.

Группа Auto scaling group имеет емкость 3.

Увы, нет. Интересный вопрос: можем ли мы использовать Vault для управления секретами в Terraform? Существуют другие способы, например переменные среды. Нет источника данных Vault для чтения секретов в Terraform. С их помощью вам не нужно вводить секреты в код, можно читать их как переменные среды.

Итак, у нас есть некоторые объекты инфраструктуры:

Вхожу в мой очень секретный VPN (не взламывайте мои VPN).

Мне, правда, стоило отметить, какая версия приложения на них запущена. Самое главное здесь, что у нас есть три экземпляра приложения. Это очень важно.


Все действительно находится за VPN:

Если я возьму это ( application-elb-1069500747.eu-west-1.elb.amazonaws.com) и вставлю в адресную строку браузера, получу следующее:

Если я выйду из системы, указанный адрес будет недоступен.
Мы видим версию 1. Напомню, я подключен к VPN. 0. 0. 0. И сколько бы мы не обновляли страницу, мы получаем 1. 0. 0.
Что произойдет, если в коде изменю версию с 1. 0. 0 до 1. 1?

filter { name = "tag:Version" values = ["1.0.1"] }

Очевидно, инструменты CI обеспечат вам создание нужной версии.
Отмечу, никаких ручных обновлений! Мы неидеальны, делаем ошибки и можем поставить при ручном обновлении версию 1.0.6 вместо 1.0.1.

filter { name = "tag:Version" values = ["1.0.6"] }

Но перейдем к нашей версии (1.0.1).

terraform plan

Terraform обновляет состояние:

Из-за изменения идентификатора он будет принудительно перезапускать конфигурацию, при этом изменится auto scaling group (это необходимо, чтобы включить новую конфигурацию запуска). Итак, в этот момент он говорит мне, что собирается изменить в конфигурации запуска версию.

Это действительно важно. Это не изменяет запущенные инстансы. Вы можете следить за этим процессом и тестировать его, не изменяя инстансы в продакшене.

Замечание: вы всегда должны создать новую конфигурацию запуска, прежде чем уничтожить старую, иначе будет ошибка.

Давайте применим изменения:

terraform apply

Когда все изменения применены, мы заходим в auto scaling group.
Перейдем к конфигурации AWS. Теперь вернемся к AWS. Они одинаковые. Мы видим, что есть три инстанса с одной конфигурацией запуска.

Вот почему мы платим им деньги. Amazon гарантирует нам, что, если мы захотим запустить три экземпляра службы, они действительно будут запущены.

Перейдем к экспериментам.

Поэтому, если я удалю один из инстансов, остальные не будут повреждены. Была создана новая конфигурацию запуска. Однако если вы используете инстансы напрямую, при этом изменяете данные пользователя, это уничтожит «живые» инстансы. Это важно. Пожалуйста, не делайте этого.

Итак, удалим один из инстансов:

На его месте появится новый инстанс. Что произойдет в auto scaling group, когда он выключится?

Инстанс будет запущен с новой конфигурацией. Здесь вы попадаете в интересную ситуацию. Иногда лучше не сразу удалять старую конфигурацию запуска, чтобы подключать по необходимости. То есть в системе у вас может оказаться несколько разных образов (с разной конфигурацией).

Почему бы не делать это с помощью скриптов и инструментов CI, а не вручную, как я показываю? Здесь все становится еще интереснее. Есть инструменты, которые могут это сделать, например отличный AWS-missing-tools на GitHub.

Это bash-сценарий, который проходит по всем инстансам в балансировщике нагрузки, уничтожает их по одному, обеспечивая создание новых на их месте.
Если я потерял один из своих инстансов с версией 1. И что делает этот инструмент? 0 и появился новый — 1. 0. 1, я захочу убить все 1. 1. 0, переведя все на новую версию. 0. Напомню, мне не нравится, когда сервер приложений живет долгое время. Потому что я всегда двигаюсь вперед.

Так что серверу было не более семи дней. В одном из проектов каждые семь дней у меня срабатывал управляющий скрипт, который уничтожал все инстансы в моей учетной записи. Еще одна вещь (моя любимая) — помечать с помощью SSH in a box серверы как «запятнанные» и каждый час уничтожать их с помощью скрипта — мы же не хотим, чтобы люди делали это вручную.

Подобные управляющие скрипты позволяют всегда иметь последнюю версию с исправленными багами и обновлениями безопасности.

Вы можете использовать скрипт, просто запуская:

aws-ha-relesae.sh -a my-scaling-group

Скрипт пройдет по всем инстансам вашей auto scaling group и заменит его. -a — это ваша auto scaling group. Вы можете сделать это даже в локальной учетной записи AWS. Запускать его можно не только вручную, но и из инструмента CI.
Вы можете сделать это в QA или на продакшене. Вы делаете все, что захотите, каждый раз используя один и тот же механизм.

У нас появился новый инстанс: Вернемся в Amazon.

0. Обновив страницу в браузере, где мы ранее видели версию 1. 0, получаем:

Интересная вещь заключается в том, что, поскольку мы создали сценарий создания AMI, мы можем протестировать создание AMI.

Есть несколько прекрасных инструментов, например ServerScript или Serverspec.

Например, ниже я привожу тест, который проверяет, что nginx установлен на сервере. Serverspec позволяет создавать спецификации в стиле Ruby, чтобы проверить, как выглядит ваш сервер приложений.

require ‘spec_helper’ describe package(‘nginx’) do it { should be_installed }
end describe service(‘nginx’) do it { sould be_enabled } it { sould be_running }
end describe port(80) do it { should be_listening }
end

Nginx должен быть установлен и запущен на сервере и слушать 80-й порт. Вы можете сказать, что пользователь X должен быть доступен на сервере. И вы можете поставить все эти тесты на свои места. Таким образом, когда вы создаете AMI, CI-инструмент может проверить, подходит ли этот AMI для заданной цели. Вы будете знать, что AMI готов к продакшену.

Вместо заключения

Мэри Поппендьек (Mary Poppendieck), вероятно, одна из самых удивительных женщин, о которых я когда-либо слышал. В свое время она рассказывала о том, как в течение многих лет развивалась бережливая разработка программного обеспечения. И о том, как она была связана с 3M в 60-х, когда компания действительно занималась бережливой разработкой.

Можете ли вы сделать этот процесс надежным и легкоповторяемым? И она задала вопрос: сколько времени потребуется вашей организации для развертывания изменений, связанных с одной строкой кода?

Сколько времени мне понадобится, чтобы устранить одну ошибку в этом приложении при развертывании на продакшене? Как правило, этот вопрос всегда касался кода ПО. Но нет причин, почему мы не можем использовать тот же вопрос применительно к инфраструктуре или базам данных.

В ней мы это называли длительностью цикла. Я работал в компании под названием OpenTable. И это относительно хорошо. И в OpenTable она была семь недель. В OpenTable мы пересматривали процесс четыре года. Я знаю компании, которым требуются месяцы, когда они отправляют код в продакшен. И мы сократили длительность цикла до трех минут. Это заняло много времени, поскольку организация большая — 200 человек. Удалось это благодаря измерениям эффекта от наших преобразований.

У нас так много инструментов и примеров, есть GitHub. Сейчас уже всё заскриптовано. Не пытайтесь реализовать все. Поэтому берите идеи с конференций, подобных DevOops, внедряйте в вашей организации. Покажите кому-нибудь. Возьмите одну крошечную вещь и реализуйте ее. Влияние небольшого изменения можно измерить, измеряйте и двигайтесь дальше!

Пол расскажет о методологии Chaos Engineering и покажет, как пользоваться этой методологией на реальных проектах. Пол Стек приедет в Петербург на конференцию DevOops 2018 с докладом «Sustainable system testing with Chaos».

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть