Сбои неизбежны, ваша задача — уменьшить ущерб: 10 советов от инженера Google, как сделать систему надежной

7-9 октября во Львове прошла конференция Lviv IT Arena 2021. Мы в Highload прослушали самые интересные выступления и делимся инсайтами с вами.

Мы уже публиковали тезисы выступления инженерки Linkedin. На очереди — лекция от SRE (Site Reliability Engineer) в Google Кристофа Ленга. У Кристофа PhD по надежным распределенным системам, и он поделился 10 советами для всех, кто тоже хочет строить системы, которым будет все нипочем.

1. Уделяйте внимание мелочам и делайте это с самого начала

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

Девиз SRE (Site Reliability Engineering) в Google: «Надежда — это не стратегия». Каждый разработчик должен всегда думать о надежности, а не надеяться на лучшее. И не только разработчик: внедрить SRE в процесс создания ПО помогает тестирование в режиме Shift Left — подход, когда тестировщики начинают свою работу как можно раньше, еще на этапе построения архитектуры.

2. Скот лучше домашних любимцев

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

Но при чем животноводство к IT? Если вы посмотрите на процесс разработки ПО и на всю IT-инфраструктуру, то окажется, что у вас могут быть либо домашние любимцы, либо скот.

Когда я работал в университете, у меня были домашние любимцы — я знал назубок названия серверов, их IP-адреса, hardware и трюки, которые нужно было сделать, чтобы заставить все работать идеально.

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

Но как тогда держать руку на пульсе и отслеживать все процессы? Помните, что скот не только многочислен, но и похож друг на друга — старайтесь строить максимально похожую архитектуру и использовать похожие технологии в разных командах.

3. Никто не виноват

Представьте ситуацию: сотрудник нажал на красную кнопку и система рухнула. Какой вопрос нужно задать? Явно не «почему он это сделал?» — это мы не сможем исправить. Вопрос должен быть «почему у нас есть эта красная кнопка?».

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

4. Измеряйте то, что важно

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

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

5. Лучший способ понять, как работает система, — это посмотреть, как она перестает работать

Пустите ее в продакшн и отправьте в свободный полет. Если вы этого не сделаете — вы не узнаете систему достаточно хорошо. Конечно, не надо просто «забивать» на нее после этого 🙂 Изучайте ее детали. Помните, что операционные проблемы обычно сложные, и легко запутаться в их причинах, если смотреть издалека.

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

6. Не геройствуйте

Героизм — это плохо. Не только для героя, но и для команды и всей системы. В книгах Гарри Поттер может сам победить Волдеморта, но реальность работает не так.

Как минимум, герой, который хочет сам все починить, выгорает. Как максимум — не справляется с этой работой. Потому что команда привыкает, что у нее есть кто-то, кто все сделает и рано или поздно появится что-то, что будет ему (или ей) не по силам.

7. Автоматизируйте свою работу

В Google команда SRE каждые 18 месяцев должна пересматривать свои ежедневные задачи и автоматизировать часть из них. Звучит страшно, но на самом деле это существенно упрощает работу — потому что если в вашей работе очень много рутинных задач, что-то здесь не так 🙂

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

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

8. Изменения — первая причина сбоев системы

Хотя изменения — это хорошо, и они необходимы для улучшения и развития системы, зачастую именно из-за них появляются и новые проблемы. Поэтому задача SRE-инженера в том числе находить баланс между надежностью системы и ее производительностью. 100% надежность невозможна, но и забывать про нее не стоит.

1. Минимизируйте риски.
2. Не тестируйте на продакшене — используйте продакшн-копию системы и тестируйте ее в условиях, максимально приближенных к реальности.
3. Используйте GitOps — храните конфигурацию в репозиториях.
4. Не деплойте в конце недели, перед отпусками или праздниками.
5. Смиритесь, что ваша система никогда не будет идеальной и бесконечно откладывать релиз — плохая стратегия.

9. Сбои неизбежны

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

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

1. Предусмотрите возможность быстро откатить изменения в любой момент.
2. Обсуждайте инциденты письменно, чтобы все оставалось задокументированным.
3. Обеспечьте прозрачность операционных процессов.
4. Читайте код, а не документацию.

10. Никаких кладбищ с привидениями

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

Как этого избежать? Строить системы как можно проще и не мириться с работой, сделанной «кое-как». Каждый кусочек кода должен быть надежной опорой, а не дверьми, которые еле держатся на петлях.