[Перевод] Хаос-инжиниринг и непрерывная проверка прода
Кейси Розенталь (Casey Rosenthal), CEO и сооснователь Verica.io, выступил на митапе Test in Production. Кейси развенчал некоторые мифы о надёжности и объяснил, что многие интуитивные действия по увеличению надёжности систем на самом деле контрпродуктивны. Более того, он объяснил, как концепция непрерывной проверки (Continuous Verification) помогает разработчикам избегать таких подводных камней.
Полное выступление Кейси:
Ведущий: 30 апреля 2020 года. Меня зовут Йоз Грэм, я защищаю интересы разработчиков в LaunchDarkly. Сегодня у нас в гостях Кейси Розенталь, CEO и сооснователь Verica.io. Привет, Кейси, спасибо, что присоединился к нам.
Кейси: Я рад быть сегодня с вами.
Ведущий: Итак, Кейси, ты тот человек, который написал книгу о хаос-инжиниринге, изданную недавно в O«Reilly, или был её соавтором.
Кейси: Ага. Написал вместе с Норой Джонс (Nora Jones). И нам помогали ещё много людей, это было замечательно. Мы собрали точки зрения сотрудников таких компаний, как Google, Slack, Microsoft, LinkedIn, Capital One и подобных.
Ведущий: Круто. Я её быстренько пролистал, там есть интересные вещи, о которых мы, надеюсь, сейчас поговорим. Потом наши зрители будут задавать вопросы. Кейси будет говорить примерно 20 минут. Начинаем.
Кейси: Отлично. Итак, я хочу поговорить о двух разных ментальных моделях и их влиянии; о том, чтобы что-то делать в проде; об эволюции, которую мы наблюдаем в DevOps, а также о лучших методиках, существующих в этой сфере.
Я работаю в компании Verica, но об этом рассказывать не буду. Подойду с другой стороны. Хочу начать с двух мифов о надёжных системах, что делает системы надёжными. Отчасти это для того, чтобы стимулировать дискуссию, а также чтобы посмотреть, как люди примут мои слова.
Мифы о надёжности
Один из мифов гласит, что вы можете сделать систему надёжнее, если уберёте людей, из-за которых возникают инциденты. То есть предполагается, что есть люди, которые больше склонны к созданию инцидентов, или менее осторожны. Иногда это связывают с концепцией управления «плохими яблоками». Однако статистика убедительно доказывает, что это заблуждение.
К сожалению, система здравоохранения в США иногда экспериментирует с такими концепциями. Например, около 80% исков о врачебных ошибках связано с 5% американских врачей. На первый взгляд, это звучит так: «очевидно, что это плохие врачи, избавьтесь от них, и количество исков уменьшится». К сожалению, всё не так: в эти 5% входят и те врачи, которые хорошо справляются с высокорискованными случаями. Поэтому они ассоциируются с большим количеством исков о врачебной небрежности. И если избавиться от этих врачей, мы лишимся людей, обладающих наибольшим опытом и знаниями о подобных случаях. То же самое относится и к вашим системам. Если у вас есть команда или сотрудник, с которым, как вам кажется, связаны проблемы надёжности, то избавление от этого человека вряд ли повысит надёжность системы.
Второй миф гласит, что нужно документировать лучшие методики и стандартные процедуры (runbooks), повышающие надёжность. Это заблуждение. Я не имел в виду, что вам не нужно ничего документировать, особенно если это позволяет эффективно взаимодействовать внутри организации. Однако большинство критически сбоев — это уникальные случаи. Для них нет лучших методик. Будем честны, в нашей сфере вообще нет лучших методик, есть лишь популярные. Мы понятия не имеем, что могло бы стать лучшей методикой в сложной системе.
Вернёмся к стандартным процедурам. Хотя они могут быть для кого-то эффективным способом взаимодействия или изложения своих личных знаний, но чтобы действительно сделать систему надёжной, вам нужны опытные люди. Одних стандартных инструкций мало. Люди не могут загружать друг другу свой опыт таким способом. Особенно такой опыт, который необходим для импровизации и внедрения.
Третий миф гласит, что если вы выявите первопричины сбоев и защититесь от них, то система станет надёжнее. Звучит очень убедительно. Повторюсь, все эти мифы интуитивны, и поэтому в них так легко верят. Но у этого утверждения есть несколько слабых мест:
- Если в сложной системе вы обнаружите уязвимости и защититесь от них, то никто не гарантирует, что вы предотвратите возникновение новых уникальных уязвимостей.
- В сложных системах не бывает первопричин. Более того, если вы анализируете их, то в лучшем случае теряете время. Отсутствие первопричин в сложных системах, как и их анализ, это бюрократическое упражнение по поиску виноватых в конкретных ситуациях. Это не идёт на пользу системе и не повышает её надёжность. Но подробнее об этом мы поговорим, когда я буду отвечать на вопросы.
Четвёртый миф гласит, что можно следить за выполнением процедур. Получается, что есть кто-то, кто лучше знает, что и как делать, а люди, выполняющие работу, на самом деле не следуют правилам. Это почти всегда ошибочно в случае с системами, которые нуждаются в повышении надёжности, особенно со сложными системами. Обычно это свидетельствует о том, насколько представления людей на более высоких уровнях расходятся с реальным положением, с тем, как на самом деле ведётся работа.
Пятый миф гласит, что если вы избегаете риска, то система становится безопаснее. Это кажется очень разумным: «не делай ничего рискованного». Сегодня мы отовсюду слышим эту фразу-ограждение. Если поставить ограждение и избегать риска, то система будет безопаснее. Однако это мешает повышению надёжности. Во-первых, люди не получают опыта, необходимого для внедрения, импровизации и использования инноваций, чтобы сделать систему надёжнее или снизить последствия инцидентов. А во-вторых, как правило, ограждения становятся препятствием для тех, кто способен лучше всего справиться с возникающими инцидентами. Повторюсь, как бы разумно ни звучал миф, на практике он контрпродуктивен.
Шестой миф гласит, что если упростить систему, она станет доступнее или надёжнее. Это проблема сложных систем. Просто уберите сложность, и система станет лучше. Здесь тоже есть подводные камни. По опыту мы знаем, что более сложные системы безопаснее или доступнее более простых систем. Это подтверждается данными. Но сложность также связана и с успешностью бизнеса. Ваши заказчики платят за сложность. Можно сказать, что работу разработчика можно охарактеризовать как добавление сложности в продукт. И если вы уберёте сложность, то вы уберёте потенциальный предел успешности вашего продукта.
Можно посмотреть на это по-другому. Случайная сложность всегда будет расти при работе над ПО. Как и неотъемлемая сложность, добавленная намеренно, которая является особенностью разработки. И поскольку оба вида сложности всегда растут, мы не выработали способов её устойчивого снижения. Так что это не сделает вашу систему надёжнее.
И последний миф: дублирование означает надёжность. Это интересное утверждение. В этой сфере предстоит многое исследовать, поскольку мы не слишком хорошо понимаем взаимосвязь между дублированием и надёжностью. Но мы уже можем привести много примеров, когда дублирование было важным фактором сбоя или инцидента. Это верно как для разработки ПО, так и для инженерии, в частности, авиа- и ракетостроения. Один из примеров — катастрофа «Челленджера». Так что в лучшем случае дублирование не влияет на надёжность.
Ментальные модели разработки ПО
Теперь поговорим о двух ментальных моделях. Мы свяжем их с разными функциями, а также с непрерывной проверкой и некоторыми другими концепциями.
Первая модель описывает, как разработчики принимают какие-то повседневные проектные решения, о которых необязательно и говорить. В рамках этой модели разработчики находятся, по сути, между трёх столпов: между экономикой, рабочей нагрузкой и безопасностью. Можете представить себе разработчиков, привязанных резиновыми жгутами к этим трём столпам. И если отойти от какого-то столпа слишком далеко, резинка лопнет и игра закончится.
Подсознательно разработчики чувствуют, насколько они далеки от столпа экономики. Возможно, в вашей компании нет правила, запрещающего разработчикам поднимать миллион экземпляров AWS EC2. А почему такого правила у вас нет? Потому что это здравый смысл. Разработчики понимают, что всё стоит денег, они сами и их команды стоят денег, и знают, что не должны тратить больше, чем у них есть. Поэтому разработчики пытаются найти баланс, принимая в течение дня какие-то решения.
То же самое и с рабочей нагрузкой (на людей или на системы). Разработчики понимают, что их серверы могут выполнить какой-то объём работы. Как и у всех людей, у разработчиков есть свои пределы работоспособности и производительности, и они ощущают взаимосвязь с этим столпом. Они делают так, чтобы не отойти от этого столпа слишком далеко, иначе их серверы будут перегружены или сами разработчики выгорят.
То же самое и с безопасностью. Отличие в том, что у разработчиков нет интуитивного ощущения, насколько они далеки от этого столпа. И я спокойно переношу эту ситуацию на всю отрасль, потому что всё ещё случаются инциденты. Утечки и взломы происходят потому, что есть сюрпризы. Если бы мы, как разработчики, знали, что должно произойти, то ради предотвращения этого остановились бы и стали делать иначе. Мы явным образом поменяли бы своё поведение.
Это одна из моделей, закладывающая основу для понимания хаос-инжиниринга. На сайте principlesofchaos.org приведено моё любимое определение:»Проведение экспериментов для выявления системных уязвимостей». Хаос-инжиниринг учит нас тому, что необходим запас прочности. Он помогает интуитивно понимать, насколько далеко мы отошли от столпа «безопасность». И это знание неявно меняет решения, которые принимают разработчики, что довольно важно.
В хаос-инжиниринге есть ряд принципов. Один из них гласит, что эксперименты нужно проводить в боевой среде. Но это не значит, что не имеет смысла экспериментировать ради выявления системных уязвимостей в staging-среде или иных непродовых средах. Имеет. Я приведу много примеров, когда это было действительно полезно.
Но в целом, если речь о сложных системах, вам стоит изучать конкретную систему, о которой вы заботитесь. Таким образом, золотым стандартом хаос-инжиниринга будет проведение экспериментов в реальной боевой среде. Это была первая ментальная модель.
Вторая модель называется «экономические столпы сложности». Это всего лишь рамки, в пределах которых мы размышляем об эволюции технологии. В этой модели есть четыре столпа:
- Состояния.
- Взаимосвязи.
- Среда.
- Обратимость.
Ярчайший пример этой модели — компания Ford в 1910-х годах, когда они могли управлять количеством состояний на производстве, заявив покупателям, что вы можете получить любую машину, какую хотите, если это чёрный Ford T. Таким образом, возможность управлять одним из четырёх столпов помогла компании ориентироваться в сложности своего производственного процесса.
Также они могли управлять взаимосвязями. У других автопроизводителей были коллективы, создававшие автомобили целиком. Форд перешёл к сборке, конвейерному производству, научному управлению и тейлоризму, чтобы ограничить количество взаимосвязей между компонентами и людьми. Это помогло ориентироваться в сложности рынка.
Компания управляла, или влияла на свою среду, сначала сформировав доверие к автомобилям в США, что позволило заниматься бизнесом. В конце концов они стали монополистом и продолжали управлять средой.
И это приводит нас к четвёртому столпу — обратимости. Здесь Ford ничего не смогла сделать, потому что включить задний ход у машины можно, а обратить вспять процесс производства невозможно. К обратимости Ford уже не смогла приспособиться.
Как эта модель применима к разработке ПО?
Состояния и функциональность приложения обычно увеличиваются. Обычно вам, как разработчику, приходится платить за добавление функций, поэтому у вас не так много возможностей по управлению этим столпом.
Взаимосвязи. К сожалению, для нашей отрасли характерно добавление уровней абстракции. Хотим мы того или нет, между движущимися частями возникают взаимосвязи. Сегодня многие из нас работаю удалённо, что усложняет человеческие взаимоотношения и обнажает архитектурные изменения, скажем, микросервисы, которые мы можем отделить от цикла доставки фич. В разработке ПО мы мало можем управлять растущим количеством взаимосвязей.
Среда. Большинство компаний-разработчиков не являются монополистами, поэтому мы не можем сильно влиять на среду.
Обратимость. Здесь сфера разработки ПО на высоте. Это прекрасно видно на примере перехода от водопадной модели к экстремальному программированию и Agile.
Водопадная модель говорит:»Мы спланируем весь продукт, создадим его и доставим заказчикам». Через год заказчик говорит:»Это не то, что я хотел. Скажу жёстко и буду жить дальше».
Экстремальное программирование говорит:»Примерно через неделю мы что-нибудь покажем заказчику». А заказчик говорит:»Это не то, что я хотел». Хорошо, решение легко обратить. Довольно легко выкинуть результаты недельной разработки. Начинается вторая неделя, мы ещё что-нибудь показываем заказчику, и надеемся, что к третьей неделе поймём, что на самом деле хочет заказчик.
Эта изощрённая реализация обратимости была способом ориентирования в новом и сложном процессе производства. Но также мы можем принимать явные архитектурные решения, которые доказывают свою обратимость. И тому есть несколько примеров получше, чем feature flag.
Переключатели feature flag помогают нам ориентироваться в сложной системе производства ПО: мы явно можем принимать обратимые архитектурные решения. И это важно. Также добавьте управление источниками, автоматизированные «канарейки» (canaries), «сине-зелёные» развёртывания (blue-green deployments) и хаос-инжиниринг как часть цикла обратной связи. Наблюдаемость как часть цикла обратной связи. Всё это улучшает обратимость и облегчает ориентирование в сложных системах.
И последнее, что я хочу сказать относительно ПО и ментальных моделей:
Главной заслугой разработки является её техническая эффективность, с премией за точность, скорость, экспертное управление, непрерывность, благоразумие и оптимальную отдачу в зависимости от входных данных.
Мертон.
Многословное, но хорошее определение разработки. Однако на самом деле я процитировал определение главной заслуги бюрократии.
И я хочу это подчеркнуть. Разработка в некоторых кругах считается бюрократической профессией. У такого мнения отрицательная коннотация. Возможно, так и есть. А зачем кому-то на это жаловаться? Ни в какой другой отрасли нет такого явного разделения на тех, кто решает, что нужно сделать; тех, кто решает, как нужно сделать; и тех, кто делает. Это идеализированная бюрократия.
Главные архитекторы, продуктологи, менеджеры проектов, управляющие, техлиды — все эти роли существуют для того, чтобы забирать ответственность за принятие решений у тех, кто выполняет саму работу. Всё это возвращает нас к тейлоризму 1910-х. Но нужно осознать, что это неправильная модель для разработки, если вы считаете, что в основе этой профессии лежат знания.
Это правильная, или приемлемая модель для создания виджетов. Но большинство из нас не делает виджеты. Так что если вы считаете, что в основе производства ПО лежит знание, то бюрократия контрпродуктивна. Я хочу сказать, что мы не пытаемся уменьшить сложность, мы пытаемся в ней ориентироваться.
Эволюция эксплуатации сложных систем
Непрерывная интеграция (continuous integration) ограничена количеством багов, которые допустимы при ускорении слияния кода, когда ошибки становятся очевиднее и не приводят к новым ошибкам. И если нам это удаётся, тогда всё нормально, инженеры могут создавать фичи быстрее.
Позднее это превратилось в непрерывную доставку (continuous delivery). Мы можем делать ПО быстрее, и нам нужно быстрее отправлять его в эксплуатацию, быстрее раскатывать, менять своё мышление. Это важная часть обратимости, возникшая благодаря эволюции.
А сейчас мы наблюдаем создание новой концепции непрерывной проверки (continuous verification):»Под капотом у нас куча очень сложного и быстро движущегося ПО. А как нам следить за дорогой? Как убедиться, что сложная система ведёт себя так, как нужно бизнесу, с учётом очень высокой скорости создания фич и отправки в прод? То есть как мы можем двигаться быстро и ничего не ломать? ».
Можно посмотреть на это с другой стороны. Непрерывная проверка — это превентивный инструмент тестирования для подтверждения поведения системы. В то время как большая часть известных отрасли инструментов тяготеют к реакционным методологиям тестирования для проверки известных свойств. Я не хочу сказать, что это плохо, напротив, хорошо и полезно. Но эти методики и дисциплины возникли во времена более простых систем и адаптированы под них. А в сложных системах приходится всё масштабировать, чтобы они обрели нужные для бизнеса свойства.
Надёжность создают не инструменты, а люди, но инструменты могут помочь.
Теперь можем перейти к вопросам.
Вопросы и ответы
Ведущий: Вы в начале предупредили нас, что будете рассказывать о том, что идёт вразрез с общепринятыми концепциями. Хочу сказать, что мы у себя проводили тестирование в боевой среде, устраивали хаос самым правильным способом, когда внешне выглядишь спокойным, а за кулисами мечешься как угорелый.
Но нужно ещё очень многое сделать. Меня несколько обескуражили некоторые ваши слова, когда вы говорили о мифах. Мне всегда казалось, что документирование и набор стандартных процедур крайне важны. Я хочу сказать, что хотелось бы больше поговорить о ценности личного опыта и о том, как это было устроено в компаниях, с которыми вы работали.
Кейси: Сначала поговорим об отказоустойчивости (resilience). Вне отрасли разработки ПО за это отвечает отдельное направление в инженерии. Думаю, самым эффективным определением отказоустойчивости будет «адаптивная ёмкость обработки инцидентов». А адаптивность требует какой-то импровизации, верно? Она требует людей, чьи навыки и знания помогают им импровизировать.
Ведущий: Верно.
Кейси: У набора процедур этого нет и не может быть. И пусть вы что-то очень хорошо задокументировали, но вы не сможете передать в стандартном наборе необходимые знания, навыки или опыт, даже для того, чтобы другой человек мог понять, что именно этому перечню процедур нужно следовать.
Если человеку нужно свериться со стандартными процедурами, то это, по сути, догадка с его стороны. А раз это догадка, то вы ограничиваете надёжность, с которой может оперировать ваша система. Вы не можете повысить надёжность, вложив больше сил в написание стандартных процедур.
Теперь о документации. Если с её помощью вам нравится взаимодействовать, прекрасно. Вам следует в этом совершенствоваться. Взаимодействие — самое сложное в большинстве профессий. Поэтому нужно пользоваться преимуществами тех способов, которые вам больше подходят, и совершенствоваться в этом. Но это не улучшит надёжность.
Ведущий: Верно. Я считаю это важным, потому что одной из самых популярных книг в последние 20 лет стала «Checklist Manifesto» Атула Гаванде (Atul Gawande). Я думаю, что некоторые концепции пришли из медицины, например, идея неукоснительного соблюдения контрольных перечней в кризисных ситуациях. Это то же самое, что и стандартные процедуры? Или между ними есть разница, которую я упустил?
Кейси: Мне кажется, разница есть. Прекрасно, если уже знакомый вам инструмент помогает выполнять работу. Но в том и отличие от стандартных процедур, которые пытаются быть достаточными, пытаются вытеснить человеческую импровизацию или адаптацию. Вы меня понимаете?
Ведущий: Да.
Кейси: Стандартные процедуры — это тактика восстановления. Чеклист нельзя использовать в качестве такой тактики. Это инструмент, который помогает вам набираться опыта.
Ведущий: Быть может, это относится к диагнозу? Чтобы можно было сделать предположения или получить полный набор фактов, прежде чем пытаться восстанавливать?
Кейси: Чаще всего чеклист не имеет отношения к восстановлению. Например, пилот, чтобы ничего не забыть, перед взлётом выполняет чеклист. Вы пытаетесь использовать инструмент из другой профессии для получения собственного нового опыта.
Ведущий: Ну да.
Кейси: Повторюсь, основное отличие от стандартных процедур…
Ведущий: Это не восстановление.
Кейси: Да.
Ведущий: Ага, хорошо. И это тоже увлекательно, учитывая, что мы зашли на территорию старых высказываний и ужасных шуток об автоматизации, возникших в период 1960–80-х. Наподобие той, что ядерным реактором управляют человек и собака; человек должен быть у пульта управления, а собака кусает человека, если тот попытается коснуться пульта.
Идея в том, что автоматизированные системы — это надёжная часть, а люди — ненадёжная органическая часть, но именно органическая природа и способность к импровизации обеспечивают надёжность.
Кейси: Обеспечивается отказоустойчивость.
Ведущий: Да, отказоустойчивость.
Кейси: У вас может быть надёжная система с обилием автоматизации. Но вы по определению не можете с помощью автоматизации сделать систему отказоустойчивее. Потому что мы пока не научились автоматизировать импровизацию.
Ведущий: Точно, и в последнее время активнее занимаются разработкой якобы самовосстанавливающихся систем. Я знаю, что некоторые компании, особенно работающие в сфере производительности, оповещения и мониторинга, создают технологии самовосстановления. Они пытаются использовать ИИ вместо выявления отклонений или установления причинно-следственных связей. Вам известно что-нибудь об успехах в этой сфере?
Кейси: Конечно. Вы можете поднять минимальный уровень надёжности, внедрив настоящие технологии самовосстановления на основе ИИ. То, что мы называем самовосстановлением, завтра назовут просто алгоритмом. Если вы посмотрите на паттерн bulwark, автоматы отключения или алгоритмы предупреждения отказов, то здесь технологии восстановления появились лет 10–20 назад. То есть систему, которая определяет аномальные отклонения и даже оповещающая об этом, можно назвать примитивной формой самовосстановления, верно?
Ведущий: Да.
Кейси: Она не делает всё сама, а использует человека вместо чего-нибудь ещё. Это совершенно правильный алгоритм повышения надёжности системы. Но повторюсь, у вас нет импровизации и контекста. Введение нового модного термина про самовосстановление не сделает вашу систему отказоустойчивее, потому что это не делает её умнее инженера, который может думать наперёд.
Мы знаем, что определяющим качеством сложной системы, в отличие от простой, является то, что сложная система не поместится в голове одного человека.
Ведущий: Верно.
Кейси: Поэтому бессмысленно полагать, что программный инженер может заранее продумать любые сбои, возможные в этой системе.
Ведущий: Да.
Кейси: А раз так, то пусть ваши алгоритмы самовосстановления будут действительно умными и подробными, но они по определению не смогут охватить все ситуации, потому что они зависят от человека, который должен заранее продумать необходимые состояния. И мы уже признали, что это невозможно.
Ведущий: Верно.
Кейси: А хаос-инжиниринг помогает людям получить опыт, который необходим для лучшей адаптации. Что может привести к улучшению автоматизации. Это может привести к алгоритмам самовосстановления или предупреждения отказов, которые сделают систему надёжнее. Но в целом, хаос-инжиниринг информирует людей о чём-то, связанном с системой, о чём они раньше не знали. И это позволяет людям неявно менять своё поведение, чтобы сделать систему надёжнее.
Ведущий: Это проясняет картину, я новичок в этом. Но создаётся впечатление, что вы утверждаете, будто надёжность и отказоустойчивость — это два разных уровня. И что отказоустойчивость является более высоким уровнем принятия решений, который вступает в игру при неудаче автоматизированных систем, которые обязательно потерпят неудачу.
Кейси: Ага. Думаю, это верная точка зрения. Я рассматриваю эти два понятия как разные свойства. Ваша система надёжна по-разному и до разной степени. Всегда есть граница, за которой надёжность теряется. Простейший пример: вы проверяете некую физическую систему нагрузочным тестированием, и в какой-то момент она в конце концов отказывает.
А отказоустойчивость не знает, откажет ли что-то. Для такого утверждения нет доказательств. Вы всегда можете сказать, ну, давайте сделаем вместо этого что-то другое. Всегда есть варианты. Невозможно перечислить все альтернативы.
Ведущий: Верно, верно. Это полностью соответствует паттерну, о котором мы говорили выше, что уровень сложности превышает наши возможности управлять ею. По сути, именно это и происходит в течение десятилетий, это гонка вооружений между сложностью и инструментами управления ею. И сложность всегда побеждает.
Кейси: Не знаю насчёт победы. Но одна из причин, по которой я люблю LaunchDarkly, заключается в том, что feature flags — явное архитектурное решение, с помощью которого вы можете облегчить себе ориентирование в сложной системе.
В разработке ПО мы притворяемся, что сложные системы — это враг. Хотя по сравнению с остальной частью нашей жизни ПО, вероятно, простейшая система, с которой приходится иметь дело людям. Подумайте о сложности человеческих взаимоотношений. Или о вождении машины, и мысленно смоделируйте, что делают другие водители. Поэтому автономное вождение до сих пор не взлетело. Разработчики не могут мысленно смоделировать других людей на дороге и их намерения. Не в смысле вычисления физики, это как раз просто.
Так что мы, как люди, даже как программные инженеры (программисты), постоянно имеем дело со сложными системами. Это основа нашей жизни. Но по ряду причин нам не нравится видеть их в своей работе. Так что по-настоящему сложные системы нам не враг. Они позволяют нам быть успешными. Но нам нужны такие вещи, как feature flags, потому что они позволяют комфортно пользоваться сложными системами, которые мы создаём. Нам нужно знать, что мы можем принять какие-то архитектурные решения, а затем быстро передумать, если понадобится.
Ведущий: Мне нравится обсуждать обратимость в разных масштабах времени. У проекта есть временна̒я шкала. Это как Agile — можно менять направление внутри одной итерации в течение пары недель. А для быстрого восстановления вы можете использовать обратимость на гораздо меньших отрезках времени.
Кейси: Если вы наняли консультанта для повышения скорости разработки фич, который сосредоточится на процессах. И это прекрасно. Вы можете, к примеру, внедрить Agile, или Scrum, или ещё что-то. Но на самом деле мы хотим повышать скорость разработки фич с помощью принятия архитектурных решений. Так комфортнее. Больше возможностей. Легче измерять. Сплошные преимущества, верно?
Ведущий: Совершенно верно. Как если бы мы получили инструмент. Если мы видим инструменты перед собой, то выгоды от процесса становятся теоретическими. Но их гораздо труднее ухватить. Когда мы видим перед собой инструменты и используем их в повседневной работе, можем переключать флаги и видеть изменения через миллисекунды — это тактильное наслаждение.
Кейси: Ага.
Ведущий: Итак, у нас уже есть замечательные вопросы. Вас часто спрашивают о том, как сделать первые шаги в хаос-инжиниринге. Но давайте сделаем шаг назад: исходя из вашего опыта, особенно с учётом мифов, где, по вашему мнению, важнее всего внедрять методики решения инцидентов?
Кейси: Я бы сначала изучил, что говорят в сообществе инженерного обеспечения отказоустойчивости об усвоенных уроках (посмертная фотография в прямом переводе). А лучше об обучающих обзорах инцидентов (learning reviews). Например, есть прекрасная статья Джона Олспоу (John Allspaw) «Blameless PostMortems» (Безобвинительные усвоенные уроки). Ей уже много лет, и я думаю, у Джона сейчас много отличного материала, потому что сегодня одних лишь безобвинительных постмортемов недостаточно.
Дело не только в том, что мы избегаем обвинений, но и в том, что в инцидентах нет виновных. В сложных системах нет первопричин. Поэтому искать их, или признавать, что «это проблема, но винить за неё некого» — не лучшее решение.
Так вот, безобвинительные обучающие обзоры — это более эффективный подход к управлению реагированием на инциденты, когда рассматриваешь их как уроки. Что касается времени восстановления (time to remediate), то моделей много, какого-то фаворита у меня нет. Различные модели используют факторы, не относящиеся к ПО, и для каких-то организаций могут работать лучше.
С одной стороны, есть координирующие модели с ролью руководителя инцидента, и вы создаёте группу в соответствии с определёнными правилами. Однако проводилось исследование, которое показало, что наличие координатора инцидента иногда может стоить дороже, чем просто группа людей, делающих обычную работу. У работников умственного труда есть инструменты и возможность принимать решения, позволяющие самостоятельно восстановить систему после инцидента.
В этой сфере было много интересных исследований. Однако я не буду давать конкретные рекомендации по восстановлению после инцидентов. По управлению реагированием есть много убедительных примеров, как нужно правильно это делать. Ну или много примеров плохих постмортемов или анализирования первопричин. Всё это указывает на процессы, которые не заставят вас терять время. Мне кажется, я окольным путём ответил на вопрос.
Ведущий: Нет, всё отлично. Безобвинительные усвоенные уроки, с которыми я сталкивался, работали хорошо. А люди вроде Оллспоу говорят о традиционных видах анализа первопричин, которые здесь неприменимы.
Кейси: Да, его компания Adaptive Capacity Labs выработала метрики, которые помогут понять, что нужно именно вам. Например, если люди предпочитают читать инструктаж после обучающих обзоров, то это говорит о том, что вы всё делаете верно.
Ведущий: У нас вопрос о feature flags. Как лучше всего управлять зависимостями, когда их становится довольно много? Думаю, я могу расширить вопрос, перейти от зависимостей к взаимосвязям как к одному из столпов сложности. Я бывал в компаниях, которые работают с большими устаревшими системами и осознают невероятное количество зависимостей, не только программных, но и организационных, и даже зависимости событий. Всё это просто невозможно отследить.
Что вы посоветуете, как управлять зависимостями в подобных случаях?
Кейси: Я не специалист по управлению зависимостями. Я знаю примеры, когда люди пасовали перед багом в виде избыточного количества неуправляемых feature flags. Думаю, в этой сфере есть много интересных подходов.
Думаю, что по мере появления над нами новых уровней абстракции полезнее будет не решать эту проблему, а ориентироваться в ней, как в проблеме сложности.
Ведущий: Согласен. Вы хотите сказать, что это может затуманивать, но может и по какой-то причине увеличить количество взаимосвязей.
Кейси: Да. И иногда причина может быть для вас не очевидна, или незначительна для достижения ваших личных целей, целей организации или бизнеса. Например мы в Verica провели в прошлом году много исследований. И заметили на рынке энтерпрайза некое разочарование в Kubernetes как в дополнительном слое в процесса развёртывания. Многим это не нравится. Kubernetes просто поддерживают как платформу, не говоря уже о том, что поиск новых способов её интеграции расценивается как дополнительная работа, которая не помогает в достижении целей более мелкого масштаба.
Это как со всплеском количества зависимостей. Если вы сосредоточены на опыте разработки и управлении зависимостями, а не на языке, или библиотеках, или инфобезопасности, то вам захочется ограничить количество зависимостей. Но если у вас бывают разные обстоятельства, и если вы пытаетесь ускорить доставку фич, то у вас возникнет противоположное желание:»Позвольте мне сделать как можно больше зависимостей, потому что я хочу брать результаты чужой работы и пользоваться ими».
В зависимости от ваших обстоятельств, у вас может быть совсем другая точка зрения на распространение зависимостей. Я считаю, что в папке «входящие» не должно оставаться писем. Но иногда важных писем приходит столько, что остаётся махнуть рукой. Я знаю, что такой подход к управлению зависимостями многих сильно разочарует, и я их понимаю. Но я в этом не специалист, так что замолкаю.
Ведущий: Ну, мне это показалось любопытной философией. Думаю, она весьма применима ко многим людям, хорошо справляющимся со сложными ситуациями. Не нужно с этим бороться. У сложившейся ситуации есть причины. Самое лучшее — научи
