Kitobni o'qish: «SRE. Рецепты выживания в продакшене для инженера по надежности», sahifa 4

45. Если что-то кажется странноватым – вам не кажется

Так называемые “подземные стуки” – вещь очень неприятная. Вроде оно пока не рвануло и катастрофы нет, но не откладывайте разбор подземного стука до момента, когда он ворвётся в вашу дверь. Не откладывайте на завтра то, что могло сломаться уже вчера.

Никто не хочет создавать себе лишнюю работу, это вполне понятно. Давайте назовём этот подход “превентивная надёжность”, что очень точно отражает желание не допускать катастрофы, а приложить подорожник немного заранее.

При возникновении такого рода “подземных стуков” я обычно говорю: “Коллеги, я хочу использовать сегодня день на то, чтобы изучить эту странную штуку”.

Один день это очень небольшая инвестиция в надёжность системы. Если я вижу странное проявление и не могу его объяснить, значит я недостаточно понимаю систему и вот есть возможность изучить её лучше.

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

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

46. Ответственны все

У нас есть внутренний процесс разбора инцидентов и я часто разбираю ситуации, когда сломался сервис A, из-за которого сломался сервис B, тем самым сломав сервис C. Сервис B и C занимают позицию “виноват другой сервис – А”, и это не то, чтобы правильно. В этой цепочке каждый компонент сработал плохо: и тот, кто сломался, и тот, кто не смог корректно обработать ситуацию сломанного смежного сервиса.

Здоровья вам и вашим сервисам. Самое непродуктивное, что в таких ситуациях можно делать, это занимать обвинительную позицию в сторону коллег. Мы все отвечаем за свои сервисы, но есть более сложная зона: стыки между сервисами, где зона ответственности размыта. Смотрите на систему как на комплекс, а не как на набор сервисов, где каждый отвечает только за свою часть. Коллаборируйтесь, привлекайте к обсуждению инцидентов коллег и ищите совместные решения по улучшению не только самих сервисов, но и взаимодействий между ними.

47. Регулярно проверяйте схемы rollback'ов

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

Организуйте для себя регулярную процедуру проверки инструментов отката релизов. С редко используемой автоматикой возможен целый ряд проблем: сломанные конфигурации, потерянные фрагменты инфраструктуры, сломанные мониторинги, потерянные доступы, изменение интерфейсов, а также наличие новичков в команде, кто уже умеет релизы выкатывать, но ещё ни разу не оказывался в ситуации, когда релиз необходимо откатить. Повторяйте процедуру проверки инструментов отката релиза хотя бы раз в квартал, если в течение этого времени вам не приходилось ничего откатывать. Мы называем этот процесс “учения по откатам”.

48. Оно нерезиновое

Если однажды вы внедрили какой-то инструмент или технологию, и продолжаете наращивать степень её использования, то лучше бы знать заранее её пределы. Иначе оно треснет тогда, когда вы этого не ожидаете. Привожу пример: когда-то давно мы в сервисе из легаси-технологий подключили keep-alive для коннектов со смежными сервисами, из которых постоянно забираем данные, чтобы не тратить время на установку соединения. Этот метод ещё называется "HTTP persistent connection". Ускорились мы тогда прилично и были этому сильно рады!

Нас было не остановить и мы переводили на этот тип подключения всё больше и больше сервисов, пока оно не взорвалось массовыми обрывами соединений. Мы-то уже привыкли, что keep-alive отлично экономит время запроса, а тут внезапно перестало работать всё. Оказалось, что у библиотеки для сетевого взаимодействия есть ограничение на одновременное удержание коннектов. У нас просто переполнился пул этих коннектов. Уже не помню, как мы это тогда решили, но это уже и неважно.

Важно, что безлимитного не существует. Если вы не достигли лимита вчера, это не значит, что вы не достигнете его завтра.

49. Доверяйте интуиции

Если перед началом каких-то манипуляций вас посещают сомнения "сделать ли бекап или не сделать", "снять трафик или оставить", "отключить или не отключать" – это ваша интуиция постукивает откуда-то снизу и как бы намекает. Не сомневайтесь – "сделайте бекап", "снимите трафик", "отключите".

Хотя если вы дочитали до этого момента, то таких сомнений уже быть не должно.

Интуиция часто вмешивается в вашу работу? Следующий совет для вас.

50. Соблюдайте регламент

Для всех плановых работ готовятся регламенты. Если регламента нет, то это не плановая работа, а непонятно что. Да, я из тех людей, кто любит надёжную систему больше, чем истории типа “А вот помнишь как мы однажды всё положили?! Да-а-а, было время!”

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

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

Нужно что-то сделать в системе? Запишитесь в очередь, то есть, возьмите талончик, то есть, заведите тикет. Мы вам перезвоним.

51. Сокращайте критические секции проводимых работ

Продолжим тему плановых работ. К этому моменту уже есть регламент работ, в котором описан тайминг и вид выполняемых работ. В основном регламентные работы предполагают отключение чего-либо в системе. Но любой компонент в системе выполняет какую-то задачу и его отключение приводит систему в менее стабильное состояние. Если плановые работы значимо влияют на надёжность сервиса, то весь сценарий работ нужно поделить на слоты, в которых длительность критических секций будет сведена к минимуму. Например, сначала нужно провести всю подготовительную работу, затем отключить критический компонент (для которого, конечно же, есть резервная система), провести работы, включить компонент обратно, а потом уже спокойно проводить завершающий этап.

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

Также существует интересный подход – бюджет на отключения. Это может выглядеть так: в течение года у вас есть N часов на проведение регламентных работ, в течение которых система работает на резервных компонентах. Этот бюджет не имеет прямого отношения к SLA, так как существует для снижения вероятности проблем.

52. Проводите работы на спаде трафика

Любой уважающий себя сервис знает, когда у него начинается подъём трафика, а когда спад. Обычно это утро и вечер. Почти всегда динамика вашего трафика имеет ярко выраженный характер, например, днём трафика в десятки или даже сотни раз больше, чем вечером. В этом случае рассмотрите возможность проведения критических работ ближе к вечеру – на спаде трафика.

Бывает, что работы пошли не по плану, пользователи начинают приходить на сервис, система работает плохо, потому что мощности её снижены – всё начинает ломаться как снежный ком, и справиться с этим достаточно тяжело.

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

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

Оценивайте риски для вашей конкретной ситуации.

Деньги: для компании почти всегда проще оплатить переработки группы сотрудников, чем нести потери от неработоспособности системы в дневное время.

53. Календарь плановых запусков и работ

О запусках и непредсказуемости.

По мнению большинства инженеров продакт-менеджеры это очень непредсказуемые хаотичные ребята, которые всегда всё делают в последний момент. За это их, конечно, не любят. На самом деле, никаких непредсказуемых запусков у продактов нет – обычно о запуске известно за пару месяцев, потому что любой запуск требует достаточно большого объёма работы.

Единственное, что нужно делать инженеру для уменьшения энтропии в этом мире продактов – иногда слезать с олимпа величия, ходить к продактам и задавать очень простой вопрос: “Коллеги, что вы планируете запустить в продукте в ближайшее время?”

Продакты, они как дети, а ни один ребёнок не хочет быть плохим, поэтому с радостью расскажут вам о своих планах, если увидят в ваших искренних глазах готовность им помочь.

Если у вас уже есть общий корпоративный календарь, то внесите туда планируемые запуски продактов, свой график регламентных работ и график “фризов” на изменения в системе. Если общего календаря нет – сделайте его. Не хотите электронный? Нарисуйте на стене табличку и приклейте в неё стикеры.

Возьмите на себя задачу координации запусков и своих работ – вам все будут благодарны.