Друзья! Хештег нашего мероприятия #DevOpsConfRussia2018. Делитесь впечатлениями, находите других участников – сделайте нетворкинг эффективнее.

А мы, в свою очередь, уже публикуем классные фотографии на страничках конференции: https://www.facebook.com/DevOpsConfRussia/posts/328221317936353

Берите пример с Антона Черноусова, делитесь в соцсетях своими впечатлениями от конференции с хэштегом #DevOpsConfRussia2018.

https://www.facebook.com/DevOpsConfRussia/photos/a.291018698323282/328297211262097

Любите ли вы стикеры так, как любим их мы?
Соберите полный набор, и тогда Kubernetes станет в два раза менее страшный :)

https://www.facebook.com/DevOpsConfRussia/posts/328326751259143

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

Но вы все-таки рассчитывайте, что завтра еще один насыщенный день. В 10:00 ждем вас полными сил для исследования новых трудных задач.

И немного эмоциональных фотографий вдогонку – смотрите, отмечайтесь:
https://www.facebook.com/DevOpsConfRussia/posts/328339844591167

Перерыв - подходящее время, чтобы полистать facebook, найти себя на фотографиях, полайкать их и пашэрить :)

Хэштег #DevOpsConfRussia2018
https://www.facebook.com/DevOpsConfRussia/photos/a.291018698323282/328800754545076/

А фотографии всё прибывают и прибывают! Участвуйте во всех активностях, чтобы точно попасть в хронику.

https://www.facebook.com/DevOpsConfRussia/posts/328873661204452

#DevOpsConf Игорь Курочкин. NextOps — что будет после DevOps. Открывающий доклад о направлениях развития DevOps. Вау-фишка Way of Ways - обобщенный путь нового движения, которое на начальной стадии порождает новые успешные практики, а потом начинает использоваться как бренд для различных паразитных практик и симулякров, которые эксплуатируют проблемы, а не решают их. И на этом этапе попытки нанести нечто полезное разбиваются о засилье этих паразитных практик. В общем, мы все знаем, что так и происходит, и это частное проявление бюрократизации, как ее исследовал Крозье, но в докладе был конкретный обобщенный путь, и это интересно. Дальше обобщенный путь наложен на DevOps и получается тоже понятная картина, DevOps уже 15 лет и как модный бренд уже прошел фазу полезного развития. Так что стоит задуматься о следующем тренде, которые Игорь назвал NextOps и который позволит сделать следующий шаг. И в докладе была попытка, на основе анализа работы отцов-основоположников DevOps и других трендах это нащупать. Это было интересно, но, на мой взгляд, не слишком перспективно, потому что опыт показывает, что гуру успешного направления очень редко становятся драйверами следующего. Хотя исключения бывают. Конспекта этой части не будет, смотрите доклад.

И тут интересно определение DevOps, которое дал Игорь. Потому что никакого нормативного определения не существует, и это - один из путей, которыми воспользовались паразитные субъекты для приватизации новой территории. Определение Игоря широкое: DevOps призван решать проблемы комомуникации, не только между разработкой и эксплуатацией, но и в других областях, и делает это общественное профессиональное движение. Проблемы решают понятным способом: через выделением паттерном и антипаттернов, и работой с ними. Что касается профессионального движения, то Игорь привел пример консорциума CNCF - Cloud Native Computing Foundation, как открытого сообщества. Наверное, было бы интересно сопоставить практики организации этого сообщества с сообществами прошлой эпохи - OMG или The Open Group.

Конкретно про DevOps надо сказать, что он проходит этап дифференциации, что естественно для каждой развивающейся практики. Появляются новые направления инженерных практик, применяемых на разных этапах конвейера поставки. По инженерным практикам у Игоря тоже широкое определение: это все, что позволяет обеспечить эффективную работы команд на большом масштабе. Тут выделяется много специализаций и направлений, в докладе были слайды. По инженерным практикам Игорь немного остановился на Relibility Engineering (SRE), который успешно развивается, и молодому Platform Engineering. Интересно, что SRE старше DevOps, ему 25 лет, но он по пути Way Of Ways находится еще на продуктивной фазе. Может быть, потому что он решал сложные инженерные задачи, в которых требовался результат - и в этих случаях не получается создавать простые симулякры.

#DevOpsConf Карапет Манасян из MOEX Group. Сколько стоит платформа? Вопреки названию, доклад - не про деньги, он про процессы, обеспечивающие платформенный подход, которые надо наладить. Конечно, процессы стоят денег, но это не главное. Рассказ был о построении платформенной конструкции в рамках MOEX Group. При этом типовой платформенный подход с полной однородностью процессов и единым технологическим стеком у них не подходит, так как бизнес - существенно гетерогенный, есть торговые решения с длинным релизным циклом, есть финтех с коротким тестированием гипотез и есть критическая инфраструктура со своими требованиям регулятором. Тем не менее, они рассматривают сделанное именно как платформу, а не как работу DevOps инженеров.

Принципиальная разница - в другом взаимодействии с разработкой. Разработка обычно относится к DevOps следующим образом: мы выдаем код, и задача DevOps - дотащить это до прода, как хотите. А платформа предполагает сервисное взаимодействие: команда платформы обеспечивает сервис конвейера доставки, а команды разработки используют этот сервис под свою ответственность. Профит разработки - в том, что команда платформы может обеспечить больший уровень сервиса своим конвейером доставки, чем команда разработки собственными силами. За счет того, что многие команды решают одинаковые задачи и при выносе их в команду платформы срабатывает эффект масштаба.

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

Структура команды платформы: change team, которая помогает командам трансформироваться, собирает запросы и обеспечивает поддержку; feature team доработки платформы и core platform, отвечающая за технологические стандарты и единые политики. Всего в ней 26 человек, еще 8 devops-инженеров в конкретных продуктовых командах, что связано со спецификой отдельных продуктов. Задачи от продуктовых команд поступают тремя способами: таск-трекер, демо-встречи платформы и заявки. Дальше идет анализ, как решить поставленную проблему, что стоит делать в платформе, а что команда может сделать, используя существующие возможности.

Про технологический стек: нет единого требования, если бизнес выбрал некоторое решение и считает его полезным, то они должны уметь включить его в конвейер поставки от платформы. Конвейер поставки - один типовой, дальше команды докручивают. Для платформы опираются на open source решения, но когда вы забираете такие решения внутрь, то вы становитесь владельцем, надо поддерживать и дорабатывать. Часто встречающаяся проблема - развернуть несколько экземлzпров решения в рамках группы, но при этом обеспечить общую авторизацию. Приходится дорабатывать, и это непросто.

Что достигли: единая точка правды инженерных практик - в платформе; от 50+ devops инженеров сократилось до 26; разработчикам стало видно что происходит на проде, эту границу сняли; платформа обеспечивает публикацию по требованию и выделение ресурсов для тестирования. И видно, что с ростом разработки линейного роста команды платформы не происходит, а по devops - было. Инженеров платформы надо обучать внутри, готовой такой специализации на рынке нет, если искать - то в вакансиях надо писать devops, отбирать и это не дешево.

#DevOpsConf Евгений Харченко из Райффайзен Банк. Как DevOps влияет на эффективность организации? Очень интересный доклад о реально наблюдаемой корреляции между показателями инженерной культуры и метриками эффективности. На масштабе 3000 сотрудников в 148 командах. Метрики касаются применения инженерных практик и интегральной производительности по модели DORA. А по культуре - на модель Ron Westrum, которая разделяет три вида: патологическую, бюрократическую и генеративную.

Деление культур опирается на 6 факторов: обмен информацией, сотрудничество, общая ответственность, отношение к ошибкам, анализ причин, улучшения, и для определения генеративной культуры они по каждому фактору сформулировали гипотезы-вопросы, которые предлагают оценить по 5-бальной шкале Лигерта от полностью несогласен до полностью согласен. Гипотезы:
* В командах происходит активный обмен информацией.
* В командах происходит взаимодействие ролей.
* Есть общая ответственность за продукт и платформу
* В командах свободно делятся информацией об ошибках и неудачах, не опасаются осуждения
* В командах Проводятся анализы причин проблем, ошибок и неудач
* В командах приветствуются новые идеи по улучшению процессов
Кроме оценки к каждому фактору есть дополнительный вопрос: надо проиллюстрировать вашу оценку примерами, например, в чем проявляется или не проявляется общая ответственность. Для таких вопросов есть варианты ответов со множественным выбором и можно написать свое.

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

#DevOpsConf Анастасия Граф. Как организовать базу знаний так, чтобы даже новичок-джун всё смог найти сам? Анастасия - из Maxim Technology, разработка для Taxi Maxim, 350 ИТ-шников распределенная команда по городам России. Доклад развивает тему доклада на #TeamleadConf-2023 (есть конспект в моем отчете), но отличается фокусировка. Тогда был рассказ о процессе и технических способах организовать документацию, а здесь фокус на результат - базу знаний с легким поиском и с соучастием разработчиков в ее поддержке. И основная задача тут - изменение культуры: переход от ситуации, когда тот к кому нужна информации, обращается в чатик или к соседу, к ситуации, когда человек сначала идет за ответом в базу знаний, и только если ответ не нашел идет его искать к соседу или в чатик, а найдя ответ - еще и дополняет базу знаний. Это именно изменение культуры. Но чтобы оно произошло должны быть предпосылки.

4 требования, они были сформулированы на слайде, а потом по каждому шел рассказ.

1) Легко делиться знаниями. Чтобы писали все, а не специально выделенный человек. Для этого надо дать возможность писать всем, в том числе джунам - у них есть вопросы, есть ответы, которые будут полезны следующему джуну. И каждому должно быть понятно, что и как написать, это обеспечивает типизация контента и шаблоны структуры с подсказками по заполнению каждого поля.

Типы страниц: термин; справочник - на каждой странице ответ на один вопрос; страница книги - ответ на сложный вопрос, собранный из простых и ссылок. Страница справочника включает историю изменений, чтобы отличать опечатки от содержательных актуализаций. В шаблон страницы книги зашит фидбэк, сразу.

2) Статья написана понятно читателю. Целевая аудитория часто шире, чем задумываешься. Есть люди, далекие от ИТ, которым тоже интересно не ходить с вопросами к ИТ. И здесь - ревью, обратная связь и легкость изменения. Перевести реакцию из "у вас непонятно" к "мне непонятно это и это".

3) Легко найти нужный материал. Тут есть проблема со сленгом - надо писать понятные названия. А еще работать с метками. У них документацию ведут сами команды, и они образуют дерево статей так как им удобно, в своей логике и ориентируются в своем пространстве. Которая отличается от логике соседней команды. А поиск нужен по всей документации, и метки помогают определить нужный набор страниц. И они помогают делать тематические подборки, на которых собирается вся необходимая информация.

4) Все материалы достоверны и актуальны на текущую дату. Самое сложно реализуемое. Что не надо перепроверять, а если нашел неверное - то заинтересован исправить. Реализуется за счет статусной модели для страниц, и за счет активного применения сборных страниц, которое позволяет править в одном месте. Статус - метка на странице: В работе, Ревью, Опубликована, На корректировку.

Итого, что нужно сделать:
* Дать возможность писать всем, включая джунов. Потому что у него есть что написать, ответить вопросы.
* Типизация контента. Шаблоны для каждого типа. Структуры с подсказками.
* Круг энтузиастов, которые пишут, либо встройка наполнения базы знаний включено в процесс.
* Порядок верификации и обновления. Нужен триггер обновления - когда и по какому алгоритму проверять, и алгоритм поиска устаревших страниц - через различные отчеты.

На этом - все. А мне во время доклада пришла мысль посмотреть на изменение культуры документирования как на процесс уборки и поддержания порядка: (1) есть пространства, где ты при необходимости убираешься сам, (2) есть - где активно сигнализируешь о беспорядке, (3) есть - где лишь жалуешься и страдаешь, а (4) есть - где игнорируешь. И задача - чтобы расширить пространства 1 и 2 каждого членов команды, обеспечив перекрыте всего пространства активистами. Это может дать другой взгляд.

#DevOpsConf Илья Барбашов из Авито. Developer Experience: обзор подходов и как мы их применяем. Доклад был четко из двух частей: теории о метриках продуктивности разработки и практика повышения этой продуктивности на основе общих механизмов продуктового подхода, примененного к разработке платформы. Связь первого и второго - сильно пунктиром. И тут отдельный вопрос - насколько эти теории все-таки помогают, что делают лучше?

Контекст: в авито 2500 инженеров, 1800 микросервисов. Платформа покрывает все от создания и разработки сервиса до выкатки и эксплуатации, содержит реестр сервисов и библиотек, связей, решение типовых задач в микросервисной архитектуре. Платформа 5 лет в разработке, очевидные задачи - решены. При этом не известно, насколько мы хороши, есть много идей фич, но профит от них их - неясен, а хочется понимать заранее. И нет product manager - эту роль выполняет сама команда, тимлиды. Итого: непонятно в какую сторону работать. А хотелось бы иметь ориентиры, например, метрика.

Поискали метрики в индустрии.
* DORA 4 метрики: как часто катите, как быстро докатываете до прода, как часто падаете, как быстро восстанавливаете. И у них есть квалификация low - medium - high - elite. У них платформа позволяет работать на уровне elite, улучшения лежат уже в русле команд. А там идет работа по team maturity model компании
* SPACE: Satisfaction and well-being, Performance, Activity, Communication and collaboration, Efficiency and flow - всеобъемлющий, но применение неясно
* Три изменения DevEx: Flow state, cognitive load, feedback loop. Более практичен, и это не CAP-теорема, можно все три улучшать.

Flow State: если инженера прерыват встречи, срочные задачи и блокеры, автономность выбора инженером задачи, понятные цели и задачи проекта - чтобы выбирать, интересные задачи. Не решается техническими средствами, это организация. В avito есть playbook, он это как-то решает.

Cognitive load: насколько надо напрячь мозг, чтобы эту задачу сделать. Непонятный фреймворк или технология, новый бизнес-домен и так далее. Делится на два типа: полезная, которая бьет в решение задачи, и паразитная - нечеткие требования и дополнительные знания, например, кубовые манифесты. Платформа снижает типовые задачи, чтобы разработчик не думал о кубернетисе, о том, что интеграция сломается - есть проверки, можно посмотреть любой сервис и так далее.

Feedback Loops: все действия, которые надо делать разработчику пока решает задачу. Компиляция, циклы запуска тестов и так далее. И pull request при итеративном code review. CI. Итеративные согласования, например, с безопасниками. Количество циклов, вероятно, убрать не сможем, а скорость повысить - да. Они здесь работают через стандартизацию - стандартизирвоанный CI/CD, линтинг, среда разработки с автоматической настройкой зависимости. Среда может поднять для тестов все зависимости, шины данных, базы данных - если нужно для тестов.

Но дальше вопрос: как эту историю мерить? Фреймворк рекомендует три метрики: ощущаемая легкость разработки, ощущаемая удовлетворенность разработчиков, ощущаемая продуктивность. Это все - субъективно.

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

Google-форма с фичами, по каждой оценки: не использую, если использую - удовлетворенность от очень недоволен до очень доволен. И обязательно поле для свободного фидбэка, по опыту половина людей пишут содержательно. Где взять список вопросов? Плохая мысль - попросить это сделать команды разработки платформы, потому что у них представление по устройству платформы, а пользователь использует иным образом. Поэтому берем CustDev и вопросы - по путям пользователя.

#DevOpsConf Екатерина Лысенко из RoboGate. Неизбежность, или Как приучить Devops-инженеров к проектированию. В докладе две части: почему надо проектировать, вторая - что такое - проектирование. И были примеры из реальных кейсов, одни - сквозные по докладу, другие - локальные.

Итак, почему надо проектировать? Есть два подхода к работе: в рамках должностных обязанностей и в рамке бизнеса в целом. Первый вариант проявляется, когда команда работы с платежами считает, что фискализация - за пределами ответственности, или busdev полагает, что его задача ограничена коммутацией контрагентов с бизнесом.

Если приземляем на devops, то работа в рамках должностных обязанностей приводит к тому, что вы все время тушите пожары, которые непрерывно возникают из-за динамики бизнеса. Но когда devops говорят о бизнесе в целом, то они часто все равно ограничиваются автоматизацией и своим пониманием, что они могут сделать. А на вопрос "почему так" отвечают "бизнес так хотел" или "100 лет работает, не трогай". И с такими невозможно говорить.

Проблема, почему devops действуют так, отчасти, в образовании - молодая специализация, университеты не готовят, они самоучки или кончали курсы, где им дали инструменты. И в результате devops не участвуют в архитектурных комитетах, а если участвуют - то не имеют права вето при принятии решений, то есть их приглашают для информирования. И в вакансиях проектирования не требуют.

На мой взгляд, тут определенный логический провал в рассуждении: почему выход за границы специализации непременно означает проектирование, и наоборот, почему работа в границах специализации не включает проектирование, ведь конвейер поставки ты же делаешь не ad hoc. На мой взгляд, ответ дает системный подход: когда ты создаешь подсистему, в данном случае - конвейвер поставки, ты, прежде всего, должен вписать ее в надсистему, а надсистемой в данном случае является работа бизнеса в целом. Внутри подсистемы можно оставаться, только если интерфейс уже кем-то определен, при чем с учетом потенциала подсистемы, а это знает именно devops. F иначе вписывание будет кривое. И в примерах необходимость проектирования была понятна, если devops не участвует, то бизнес прибегает с неразумными решениями.

Проектировщик решает следующие задачи:
* разработка продукта в соответствии с бизнес-вызовами
* поддержка и развития уровня качества продукта
* исполнение технической стратегии
* взаимодействие между бизнес-юнитами

Для решения ему надо понимать 5 проекций. Катя показывала их как уровни, но, на мой взгляд, это не совсем верно.
* Business vision. Полный, включая цели и не автоматизированные сценарии. Именно на этом уровне часто есть альтернативные варианты решений
* System vision. B тут часто надо обобщить разнородные частные решения, которые дали разные команды
* Integration vision. API, и там важно описывать содержание, бизнес-логику взаимодействия, которые лежат за пределами swagger
* Infrastructure vision. Он проявляется наверх, например, есть платежный провайдер, в какой-нибудь стране, где странно пополняют счета меняет json - и сообщения перестают проходить из-за кем-то поставленного ограничения в 1мб.
* Management vision: стратегии, культура. Компания меняет культуру от хакеров с крафтерам: не давай-давай, а тщательно делаем с архитектурой и рисками. И это - напрямую влияет на devops.

Проектирование - не только в крупном. Когда вы делаете анализ инцидента и пишете PIR, то там не так важно, как прошел инцидент. Важно - как не повторить, что изменить, какие меры применить. А это - проектирование.

Для архитектурных решений важно писать ADR - architecture decision report: почему решение было принято и какие последствия влечет. Они позволяют помнить причины решений, найти риски и ретроспективно работать, понимать причины выбора меньшего из нескольких зол, когда решение трогает за душу многих. Только его не надо писать на все решения, иначе получится большое множество очевидных документов, в которых не найдешь ценное.

#DevOpsConf Константин Ожерельев из Ozon. DevOps для 1C-приложений. Если кратко, то доклад был о том, что DevOps для 1С - есть. Нужен ли он - вопрос к бизнесу, у них создание DevOps инициировано требованиями аудиторов по устойчивости процессов обновления софта для публичной компании. Но эффект не ограничивался удовлетворением аудиторов, реально получена устойчивость прода за счет автоматизации доставки обновлений и разработки автотестов, выполняемых в конвейере доставки.

И в докладе были подробности - за счет каких именно средств это достигается, и как организовано. Конвейер доставки есть для обоих вариантов разработки: EDT + Git и Конфигуратор + Хранилище (собственная система контроля версий от 1С). Вариант Конфигуратор + Git формально существует, но фактически рабочим не является, поэтому не рассматриваем. Стартом для процесса DevOps в обоих случаях служит Git, просто при использовании хранилища синхронизация с Git обеспечивается отдельной утилитой GitSync. При этом не получается использовать feature branch, разработка ведется в единой dev-ветке, а чтобы иметь возможность исключать функционал отдельных фич из обновления используют стандартный паттерн feature toggle. А дальше все стандартно: dev - test - release со своими средами развертывания и тестирования. Для того, чтобы в конвейере процессе сборки выполнять скрипты, в том числе специфичные для 1С используется OneScript - продукт, который позволяет писать скрипты на языке 1С, исполняемые вне среды, работает поверх .Net и .NetCore. Смысл OneScript в том, что язык получается знаком 1С-разработчиком и их может поддерживать сама команда 1С. В мире 1С принято, что развертывание поддерживает команда, а не отдельные devops. Об остальных средствах - смотри презентацию на слайдах.

На этом про доклад - все, а от себя отмечу, что первый доклад про реализацию CI/CD для 1С я слышал уже лет семь назад, другое дело, что сам вендор не торопится с полноценной поддержкой, и разработчики консервативны. Но технические возможности - есть и они совершенствуются.

#DevOpsConf Владимир Утратенко из Uzum Market. Древние свитки CI/CD: смыслы, которые мы потеряли. Это был доклад за все хорошее против всего плохого. О том, что не взирая на лучшие практики, многие по-прежнему работают по-старому. Хранят код, конфигурации, тесты и описание конвейера в разных репозиториях с непонятной синхронизацией, а кое-что может лежать вообще вне репозиториев. Что запуск тестов, особенно нагрузочных, и разворачивание среды для этого может быть магией, доступной отдельному инженеру. Что патчи могут собираться вручную и пересылаться по почте. А если тесты запускаются автоматом и падают, то разработчики могут их отключать, а не чинить, или просто игнорировать. Что никакой integration в рамках CI не происходит, а просто сборка отдельного продукта. А реальный continuous delivery - вообще редкий зверь, потому что на пути к проду часто стоит ручной регресс, который делают много месяцев. Что несмотря на рекомендации делать частые коммиты и мержить ветки, разработчики накапливают изменения несколько месяцев в стремлении сделать все-все-все, а потом мерж фичи занимает несколько недель и приводит к переписыванию заново, потому что этот же код активно правили. И вообще, CI/CD для части людей превратились в buzzword, смысла которого они не понимают. И все это - с одобрением аудитории, которой эти проблемы известны.

К сожалению, от того, что людям лишний раз напоминаешь про хорошие практики, они начинают их использовать. Сколько человек по утрам делают зарядку или ходят в фитнес? А скольких можно побудить к этому, рассказав про ожирении и разные проблемы, которые ждут в будущем, или даже в настоящем? Увы! Так что тут, по-хорошему, нужен серьезный разбор причин и способов работы, включая методы изменения привычек и культуры - ведь проблема-то в них. Впрочем, доклад был хороший и с юмором, так что, не исключаю, что, слушая его, участники увидят на свой портрет в сатирическом зеркале и решат измениться.

#DevOpsConf Сергей Реусин из СберМаркет. Инженерия устойчивости как основной инструмент выживания вашей организации: история, подходы и примеры внедрения. Это был доклад первого дня, на который я забыл опубликовать конспект. Доклад концептуальный, он принципиально меняет точку зрения на ошибки и сбои: мы не стремимся уменьшить их до нуля, увеличив время между ошибками, а определяем допустимую зону и фокусируемся на способах быстрого восстановления в случае сбоев. И это дает устойчивость системы в целом. Это подход resilience engineering, основанного на работах ряда исследователей. В их числе Richard Cook, на работы которого Сергей много ссылался. Предлагается определить зону сбоев, которая является приемлемой, и держаться в ней, в том числе - за счет быстрого восстановления, а не только за счет снижения количества ошибок. Подробнее про подход можно посмотреть в stella.report. Идея состоит в том, что мы предусматриваем универсальные способы восстановления, которые сработают в широком спектре ситуаций. И что наоборот, частные способы могут перестать работать. Например, практика канареечных релизов, при которой новые фичи сначала предоставляются малому числу пользователей для проверки работоспособности, могут перестать выполнять свою функцию, если разработчики начнут применять feature toggle, включаемые сразу и для всех, а не постепенно - сначала релиз раскатят на всех, а потом этот флаг возьмут и включат, и проблемы посыпятся.

Это - интересный взгляд. Потому что в погоне за высокой доступностью часто применяют сложные и дорогие технические решения, и несут неоправданные затраты. В то время как альтернативные способы могут быть гораздо легче. Я тут поделюсь своим опытом. В свое время мы проектировали систему розничного магазина для Спортмастера, и спросили их - а могут же быть разные проблемы с работой системы: электричество, сеть и так далее. А они рассказали, что на этот случай есть план-Б: автономный сканер ШК (ТСД), в который загружен каталог с актуальными ценами, и который умеет фиксировать продажи, сканируя ШК, и простая дешевая касса, на которой можно пробивать чеки в автономном режиме и которая работает от обычного бесперебойника, и в результате при любых проблемах магазин 6 часов способен вести продажи. Что позволяет не слишком заморачиваться с доступностью именно информационной системы. И аналогичный подход у них дальше применялся при переходе на централизованную систему лояльности: при сбоях интернета владельцам карт предоставлялась специальная скидка, размер которой их обычно удовлетворял, так что проблемы не вызывали негатива. И как побочный эффект такое решение снижало требования к доступности централизованной системы лояльности - план-Б со специальной скидкой работал и в этом случае.