Кейси Розенталь (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 просто поддерживают как платформу, не говоря уже о том, что поиск новых способов её интеграции расценивается как дополнительная работа, которая не помогает в достижении целей более мелкого масштаба.
Это как со всплеском количества зависимостей. Если вы сосредоточены на опыте разработки и управлении зависимостями, а не на языке, или библиотеках, или инфобезопасности, то вам захочется ограничить количество зависимостей. Но если у вас бывают разные обстоятельства, и если вы пытаетесь ускорить доставку фич, то у вас возникнет противоположное желание: «Позвольте мне сделать как можно больше зависимостей, потому что я хочу брать результаты чужой работы и пользоваться ими».
В зависимости от ваших обстоятельств, у вас может быть совсем другая точка зрения на распространение зависимостей. Я считаю, что в папке «входящие» не должно оставаться писем. Но иногда важных писем приходит столько, что остаётся махнуть рукой. Я знаю, что такой подход к управлению зависимостями многих сильно разочарует, и я их понимаю. Но я в этом не специалист, так что замолкаю.
Ведущий: Ну, мне это показалось любопытной философией. Думаю, она весьма применима ко многим людям, хорошо справляющимся со сложными ситуациями. Не нужно с этим бороться. У сложившейся ситуации есть причины. Самое лучшее — научиться ориентироваться, диагностировать.
Мне это близко, потому что я выступал по поводу отладки. Оказалось, что очень многие не осознают широты возможностей и простоты использования собственных отладчиков. Не понимают, насколько важно настраивать инструменты под конкретную ситуацию. У меня редко бывало так, чтобы инструмент, созданный под систему, не окупал себя за пару месяцев.
Кейси: Это способ для вас, как инженера, лучше ориентироваться в сложной системе: вы создаёте специальный инструмент. Да, это разумно.
Ведущий: Многие задают вопросы о хаос-инжиниринге. «Как мне начать применять это в моей организации? И как мне убедить в этом руководство?» Полагаю, всё зависит от того, как это преподнести. А какой совет вы даете в таких ситуациях?
Кейси: Я слышал, недавно вышла хорошая книга на эту тему [намекает на свою книгу «Chaos engineering»]. Общий совет — начните с игрового дня (game day). Есть куча способов, как это организовать. По сути, нам нужно собрать людей с необходимым опытом и начать обсуждение последствий, или аномального поведения системы. Одно лишь обсуждение часто помогает вскрыть нехватку знаний о фактическом поведении системы.
Итак, игровой день, вы собрались в комнате и решаете остановить какой-то фрагмент инфраструктуры на несколько часов. Вы предполагаете, что это не повлияет на клиентов. Гипотеза для хаос-эксперимента с доступностью почти всегда строится по шаблону: «При таких-то условиях клиенты всё ещё будут чувствовать себя хорошо».
Если вы считаете, что при таких-то условиях клиенты почувствуют себя плохо, то не проводите такой эксперимент. Это будет просто ужасно.
Ведущий: Ага.
Кейси: Кто-то говорит про хаос-инжиниринг, что это смело, или слишком рискованно. Нет, это не должно быть рискованно. Если вы считаете, что что-то сломается, то просто не делайте этого. Сначала исправьте, прежде чем что-то делать.
Ведущий: Верно.
Кейси: Хаос-инжиниринг — это не про вызов хаос-инженеров и не про создание хаоса в вашей системе. Считается, что он в ней уже присутствует. И если вы попытаетесь обнажить его, то это поможет вам лучше избегать подводных камней. И всё. Прекрасный способ для начала. Спланируйте игровой день или сценарий, а затем продолжайте углубляться в этом направлении.
Это золотой стандарт проведения хаос-инжиниринга в боевой среде. Но я рекомендую начать со staging-среды, если она у вас есть. Многие компании от неё отказываются, и это можно понять. Feature flags немножко помогают. Но если у вас есть staging-среда, или скрытые фичи, или разные группы пользователей, связанные с разными фичами, то начните экспериментировать там. Нет причин этого не делать.
Надеюсь, вы узнаете что-то полезное своей о staging-среде и о системе, что поможет вам сделать их надёжнее. Или вы получите навыки по обеспечению отказоустойчивости. Или станете увереннее ориентироваться в системе, и эта уверенность поможет вам провести те же эксперименты с теми же инструментами в production-среде.
Ведущий: Верно.
Кейси: Такую эволюцию мы наблюдаем.
Ведущий: Отлично сказано. У нас в LaunchDarkly есть staging-среда. Мы не стали от неё отказываться и всё делать в production, потому что если можно уменьшить опасность эксперимента, то нужно это сделать. Тестировать в production нужно потому, что вы и так уже это делаете. Просто не называете тестированием.
Напоследок хочу спросить. Вы говорили о проблеме «плохих яблок», что люди, которые становятся причиной проблем, на самом деле не являются плохими сотрудниками. Просто их послали сделать это…
Кейси: Да, так чаще всего и происходит. Мы не используем слово «причина», потому что это подразумевает, что эти люди являются первопричиной.
Ведущий: Верно, извините, вы абсолютно правы. Проходившие мимо, те, кто оказался поблизости, главные подозреваемые.
Так вот, я работал в Linden Labs, и там узнал больше всего о сложных устаревших системах. Если совершённая тобой ошибка рушила боевую среду, ты должен был в течение дня носить [неразборчиво]. Я знаю и другие компании, в которых так делается. Но как объяснили моему коллеге, это на самом деле знак отличия. Ты попробовал что-то, сделал что-то важное, исправил что-то важное и научился. Я знаю, что в Etsy для этого используют свитер с тремя рукавами. А какие интересные символы известны вам?
Кейси: В Netflix то ли дают бейджи, то ли забирают за то, что ты уронил боевую среду. В Google есть ритуал. Я это понимаю и принимаю. Не могу сказать, что полностью поддерживаю, потому что это символизирует, что человек стал причиной проблемы. Обычно такое происходит случайно, саботаж встречается крайне редко.
Если у тебя не было плохих намерений, то в сложной системе нет причинно-следственных связей. Это поправка к размышлениям о том, чем инцидент отличается от того, что человек опубликовал одну строку кода, которая уронила production. Вы говорите о том, что минимальные усилия по восстановлению — это откат строки кода.
Но есть и другие точки зрения. Человек, написавший инструмент непрерывной доставки, виноват в том, что не реализовал автоматический staging. Или руководители виноваты в недостаточности коммуникации. Или директор виноват в недостаточном бюджетировании ещё одной среды. Или вице-президент виноват в том, что не объяснил правлению, почему нужен этот бюджет, и не выбрал другой инструмент доставки. Или технический директор виноват в том, что не объяснил важность инструмента.
Что из этого с большей вероятностью позволит создать более надёжное решение? Надевание свитера с тремя рукавами на человека, который отправил в production строку кода, или изменение поведения технического директора? Второе с большей вероятность повысит надёжность системы. А все эти дела с RCA и сосредоточенность на одном человеке вообще не повлияют на надёжность системы. Свитер с тремя рукавами комфортнее, поэтому позор их не смущает, и это важно. Но при этом вы застреваете на мысли, что виноват этот человек, а не технический директор.
Ведущий: Интересно. Это указывает на то, что есть большая разница между анализом записей и тем, как я бы задал руководству пять вопросов «почему»: почему произошло, одно, второе, третье и т.д.
Кейси: Как говорит Ричард Кук (Richard Cook), «у меня шестилетний ребёнок, и он прекрасно спрашивает «почему», его можно отправить заниматься восстановлением после инцидентов». Проблема «пяти почему» в том, что вопросы совершенно произвольны. И спрашивающий может преследовать свои интересы. Если я директор, то буду спрашивать об отчётах, и плохом взаимодействии. А если спрашивает сотрудник с нижних уровней иерархии, то вопросы могут быть связаны с языком С. Так что «пять почему» не слишком помогают в расследовании. Я предпочту этим не пользоваться. Но я понимаю, что в некоторых организациях, в руках хорошо информированного человека с благими намерениями этот инструмент может сделать расследование более приемлемым.
Ведущий: Да, всё зависит от точки зрения. Парадокс в том, что если вы смотрите на ситуацию снизу, то ситуация может быть видна лучше. Но при этом у вас меньше влияния на неё.
Кейси: Другое повествование, верно? Кто сказал, что одна точка зрения точнее другой. Но в случае с иерархией интуиция подсказывает, что для изменения всей системы гораздо эффективнее повлиять на людей на вершине иерархии.
И если говорить о надёжности, то нужно смотреть на систему в целом, а не на сотрудников на передовой.
Ведущий: Правильно. Если тебе платят большую зарплату за то, чтобы ты был наверху, то у тебя есть возможности что-то исправить. Будем надеяться.
Это было очень интересно, но нам пора заканчивать. Спасибо, что присоединились к нам сегодня.
Кейси: Спасибо, что пригласили.
Полное выступление Кейси:
Ведущий: 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 просто поддерживают как платформу, не говоря уже о том, что поиск новых способов её интеграции расценивается как дополнительная работа, которая не помогает в достижении целей более мелкого масштаба.
Это как со всплеском количества зависимостей. Если вы сосредоточены на опыте разработки и управлении зависимостями, а не на языке, или библиотеках, или инфобезопасности, то вам захочется ограничить количество зависимостей. Но если у вас бывают разные обстоятельства, и если вы пытаетесь ускорить доставку фич, то у вас возникнет противоположное желание: «Позвольте мне сделать как можно больше зависимостей, потому что я хочу брать результаты чужой работы и пользоваться ими».
В зависимости от ваших обстоятельств, у вас может быть совсем другая точка зрения на распространение зависимостей. Я считаю, что в папке «входящие» не должно оставаться писем. Но иногда важных писем приходит столько, что остаётся махнуть рукой. Я знаю, что такой подход к управлению зависимостями многих сильно разочарует, и я их понимаю. Но я в этом не специалист, так что замолкаю.
Ведущий: Ну, мне это показалось любопытной философией. Думаю, она весьма применима ко многим людям, хорошо справляющимся со сложными ситуациями. Не нужно с этим бороться. У сложившейся ситуации есть причины. Самое лучшее — научиться ориентироваться, диагностировать.
Мне это близко, потому что я выступал по поводу отладки. Оказалось, что очень многие не осознают широты возможностей и простоты использования собственных отладчиков. Не понимают, насколько важно настраивать инструменты под конкретную ситуацию. У меня редко бывало так, чтобы инструмент, созданный под систему, не окупал себя за пару месяцев.
Кейси: Это способ для вас, как инженера, лучше ориентироваться в сложной системе: вы создаёте специальный инструмент. Да, это разумно.
Ведущий: Многие задают вопросы о хаос-инжиниринге. «Как мне начать применять это в моей организации? И как мне убедить в этом руководство?» Полагаю, всё зависит от того, как это преподнести. А какой совет вы даете в таких ситуациях?
Кейси: Я слышал, недавно вышла хорошая книга на эту тему [намекает на свою книгу «Chaos engineering»]. Общий совет — начните с игрового дня (game day). Есть куча способов, как это организовать. По сути, нам нужно собрать людей с необходимым опытом и начать обсуждение последствий, или аномального поведения системы. Одно лишь обсуждение часто помогает вскрыть нехватку знаний о фактическом поведении системы.
Итак, игровой день, вы собрались в комнате и решаете остановить какой-то фрагмент инфраструктуры на несколько часов. Вы предполагаете, что это не повлияет на клиентов. Гипотеза для хаос-эксперимента с доступностью почти всегда строится по шаблону: «При таких-то условиях клиенты всё ещё будут чувствовать себя хорошо».
Если вы считаете, что при таких-то условиях клиенты почувствуют себя плохо, то не проводите такой эксперимент. Это будет просто ужасно.
Ведущий: Ага.
Кейси: Кто-то говорит про хаос-инжиниринг, что это смело, или слишком рискованно. Нет, это не должно быть рискованно. Если вы считаете, что что-то сломается, то просто не делайте этого. Сначала исправьте, прежде чем что-то делать.
Ведущий: Верно.
Кейси: Хаос-инжиниринг — это не про вызов хаос-инженеров и не про создание хаоса в вашей системе. Считается, что он в ней уже присутствует. И если вы попытаетесь обнажить его, то это поможет вам лучше избегать подводных камней. И всё. Прекрасный способ для начала. Спланируйте игровой день или сценарий, а затем продолжайте углубляться в этом направлении.
Это золотой стандарт проведения хаос-инжиниринга в боевой среде. Но я рекомендую начать со staging-среды, если она у вас есть. Многие компании от неё отказываются, и это можно понять. Feature flags немножко помогают. Но если у вас есть staging-среда, или скрытые фичи, или разные группы пользователей, связанные с разными фичами, то начните экспериментировать там. Нет причин этого не делать.
Надеюсь, вы узнаете что-то полезное своей о staging-среде и о системе, что поможет вам сделать их надёжнее. Или вы получите навыки по обеспечению отказоустойчивости. Или станете увереннее ориентироваться в системе, и эта уверенность поможет вам провести те же эксперименты с теми же инструментами в production-среде.
Ведущий: Верно.
Кейси: Такую эволюцию мы наблюдаем.
Ведущий: Отлично сказано. У нас в LaunchDarkly есть staging-среда. Мы не стали от неё отказываться и всё делать в production, потому что если можно уменьшить опасность эксперимента, то нужно это сделать. Тестировать в production нужно потому, что вы и так уже это делаете. Просто не называете тестированием.
Напоследок хочу спросить. Вы говорили о проблеме «плохих яблок», что люди, которые становятся причиной проблем, на самом деле не являются плохими сотрудниками. Просто их послали сделать это…
Кейси: Да, так чаще всего и происходит. Мы не используем слово «причина», потому что это подразумевает, что эти люди являются первопричиной.
Ведущий: Верно, извините, вы абсолютно правы. Проходившие мимо, те, кто оказался поблизости, главные подозреваемые.
Так вот, я работал в Linden Labs, и там узнал больше всего о сложных устаревших системах. Если совершённая тобой ошибка рушила боевую среду, ты должен был в течение дня носить [неразборчиво]. Я знаю и другие компании, в которых так делается. Но как объяснили моему коллеге, это на самом деле знак отличия. Ты попробовал что-то, сделал что-то важное, исправил что-то важное и научился. Я знаю, что в Etsy для этого используют свитер с тремя рукавами. А какие интересные символы известны вам?
Кейси: В Netflix то ли дают бейджи, то ли забирают за то, что ты уронил боевую среду. В Google есть ритуал. Я это понимаю и принимаю. Не могу сказать, что полностью поддерживаю, потому что это символизирует, что человек стал причиной проблемы. Обычно такое происходит случайно, саботаж встречается крайне редко.
Если у тебя не было плохих намерений, то в сложной системе нет причинно-следственных связей. Это поправка к размышлениям о том, чем инцидент отличается от того, что человек опубликовал одну строку кода, которая уронила production. Вы говорите о том, что минимальные усилия по восстановлению — это откат строки кода.
Но есть и другие точки зрения. Человек, написавший инструмент непрерывной доставки, виноват в том, что не реализовал автоматический staging. Или руководители виноваты в недостаточности коммуникации. Или директор виноват в недостаточном бюджетировании ещё одной среды. Или вице-президент виноват в том, что не объяснил правлению, почему нужен этот бюджет, и не выбрал другой инструмент доставки. Или технический директор виноват в том, что не объяснил важность инструмента.
Что из этого с большей вероятностью позволит создать более надёжное решение? Надевание свитера с тремя рукавами на человека, который отправил в production строку кода, или изменение поведения технического директора? Второе с большей вероятность повысит надёжность системы. А все эти дела с RCA и сосредоточенность на одном человеке вообще не повлияют на надёжность системы. Свитер с тремя рукавами комфортнее, поэтому позор их не смущает, и это важно. Но при этом вы застреваете на мысли, что виноват этот человек, а не технический директор.
Ведущий: Интересно. Это указывает на то, что есть большая разница между анализом записей и тем, как я бы задал руководству пять вопросов «почему»: почему произошло, одно, второе, третье и т.д.
Кейси: Как говорит Ричард Кук (Richard Cook), «у меня шестилетний ребёнок, и он прекрасно спрашивает «почему», его можно отправить заниматься восстановлением после инцидентов». Проблема «пяти почему» в том, что вопросы совершенно произвольны. И спрашивающий может преследовать свои интересы. Если я директор, то буду спрашивать об отчётах, и плохом взаимодействии. А если спрашивает сотрудник с нижних уровней иерархии, то вопросы могут быть связаны с языком С. Так что «пять почему» не слишком помогают в расследовании. Я предпочту этим не пользоваться. Но я понимаю, что в некоторых организациях, в руках хорошо информированного человека с благими намерениями этот инструмент может сделать расследование более приемлемым.
Ведущий: Да, всё зависит от точки зрения. Парадокс в том, что если вы смотрите на ситуацию снизу, то ситуация может быть видна лучше. Но при этом у вас меньше влияния на неё.
Кейси: Другое повествование, верно? Кто сказал, что одна точка зрения точнее другой. Но в случае с иерархией интуиция подсказывает, что для изменения всей системы гораздо эффективнее повлиять на людей на вершине иерархии.
И если говорить о надёжности, то нужно смотреть на систему в целом, а не на сотрудников на передовой.
Ведущий: Правильно. Если тебе платят большую зарплату за то, чтобы ты был наверху, то у тебя есть возможности что-то исправить. Будем надеяться.
Это было очень интересно, но нам пора заканчивать. Спасибо, что присоединились к нам сегодня.
Кейси: Спасибо, что пригласили.
Моё личное мнение, как CTO, или «сухая выжимка»
На мой взгляд, это был глубокий философский разговор, основная суть которого — надежностью необходимо заниматься профессионально и с поправкой на архитектуру и возможности твоей организации. А также то, что тестирование на проде или «постоянная проверка» — необходимый процесс для разработки ПО, потому что взаимосвязей становится всё больше, сами системы становятся всё сложнее. Протестировать все в QA-средах невозможно, необходимо обязательно иметь включатели фич для быстого выключения функциональности. И процесс разработки строить так, чтобы можно было безболезненно откатить последние изменения.
Я точно не согласен с Кейси, что не доказана польза дублирования. Если бы она была не доказана, то у человека был бы один глаз на лбу и одно ухо где-нибудь на подбородке. А также у самолета был только один двигатель. Без стандартных процедур также не обойтись, это вопрос, прежде всего, сменяемости команды и масштабирования. Ты не можешь одномоментно получить в свою команду профессионалов, ты выращиваешь их из джунов и мидлов в том числе на базе стандартных процедур. Это фундамент для роста и масштабирования, а также незамыкания знаний в одной голове. В терминах ИТ — «уменьшение бас—фактора».
