Мой путь в SRE
Артем Артемьев, Lead SRE в компании Tango Me, повидал разный SRE. Прорабатывая программу четвёртого интенсива Слёрм «SRE: внедряем DevOps от Google», мы решили провести ещё и открытое интервью с Артемом. Он пошагово и обстоятельно делится своим 12-летним опытом в этой сфере, не скрывая трудностей и открыто говоря о требованиях к кандидатам.
Когда SRE один, а в каждой компании его воспринимают и используют по-разному, возникает множество вопросов и сомнений. Артем развеял большую часть из них, приведя личные примеры и комментируя каждый из них.
Как я начинал
Сначала хочу сказать о каком SRE пойдет речь и почему не о DevOps. Я расскажу не о том SRE, который придумал Google, а о том SRE, который случился в России, в Беларуси и других странах.
Самим SRE я занимаюсь года четыре, а за надежность как таковую отвечаю уже лет восемь. Мой путь к SRE был долгим. Я немного знал Linux и пошел устраиваться в техническую поддержку компании FirstVDS в Иркутске. Я проработал там 12 лет. В какой-то момент мне стало скучно, захотелось чего-то нового. И вот тогда я начал проходить собеседования, тренироваться отвечать на разные вопросы о моем опыте и знаниях, да еще и на английском языке.
Мне предложили позицию SRE в одной большой игровой компании в Минске. Работать там было интересно, потому что в компании было много разных продуктов, отделов, инженерных решений, но не было человека, который бы точно разбирался во всём.
Про инцидент на продакшене
Проблемы часто случаются где-то «посередине». То есть микросервисы — это хорошо, но вся сложность заключается в стрелках между ними. У нас были дежурные, которых можно было разбудить ночью, сказать, что что-то не работает. Они находили, в каком месте байтики перестали «ходить», что сломалось, понимали, кто ответственный за ту или иную проблему. Эти дежурные либо чинили поломку сами, либо понимали, что ничего страшного не произойдет и можно дождаться утра, и ложились спать. А бывало и такое, что ты просыпаешься ночью, видишь проблему и понятия не имеешь, как ее решать.
Приведу пример. У игровой компании был шутер. Суть в том, что люди, собираясь в команды, бегают и стреляют друг в друга. Как-то ночью меня будят и говорят про игру, название которой я слышу впервые. В этой игре в составе команды есть врач. Игрок приобрел новую одежду для всех участников команды, а у врача как был белый халат, так и остался. Произошел инцидент на продакшене. Что я делаю? Я поднимаю ночью все байтики и нахожу, что в том, который присылается в игру, врачу не полагается никакой формы, то есть игрок должен быть только в белом халате и всё.
Про разницу между SRE и DevOps
Я отмечаю для себя один факт: DevOps неплох, и концепцию придумали, чтобы разработка и эксплуатация подружились. Но в какой-то момент на этапе внедрения DevOps-манифеста случилось непоправимое, и DevOps превратился в пайплайн и доставки. То есть компании внедрили DevOps, но проблемы с надежностью сервисов и с тем, кто будет за них отвечать, остались.
В этот момент бизнес решил, что нужны новые люди, и встал вопрос: как их назвать? DevOps у нас уже есть, назвать еще один отдел «DevOps» будет неправильно, поэтому нанимают примерно тех же людей, что нанимали в DevOps, но называют их SRE. В зависимости от «болезней», от того, где компании «больно», SRE начинают выполнять немного отличные от DevOps функции и роли, но все они всё равно связаны с тем, чтобы продакшен работал стабильно. Если говорить о повседневных задачах SRE-инженеров, то мы занимались деплоями и дежурством. Что-то еще делать мы просто физически не успевали.
Инструменты SRE
SRE требуются приборы для мониторинга. Они тебе нужны, чтобы понимать, что происходит, когда случился какой-то инцидент и в нем нужно разобраться. Стандартный набор — это SSH, tcpdump, top. Также это Prometheus, Grafana, Alertmanager, PagerDuty. Очень удобно в работе использовать какой-нибудь трекер задач. У нас была хорошо переписанная JIRA. В ней фиксировался каждый инцидент, который она помещала вверху тикета, а все предыдущие прикрепляла ниже. То есть я мог посмотреть, как ранее ребята решали точно такую же проблему. Внутри этого тикета задача адресовывалась тем людям, которые могли с ней справиться. Это работало очень здорово.
Опыт работы в Inspectorio
Inspectorio делает программный продукт для проверки качества одежды на фабриках. Например, вашу футболочку отшили. Теперь необходимо проверить, что она соответствует заданному стандарту: нитки нигде не торчат, цвет тот, что нужен, размер правильный. В этом процессе всё было ближе к тому, как написано в книжке Google. У бизнеса были вопросы к надежности продукта, но не было вопросов к DevOps. Моей задачей была необходимость обозначить пять основных функций в Inspectorio и привнести понимание того, насколько надежно они работают.
О работе в Tango Me
Наверное, все уже знают про существование стримов. В странах СНГ не настолько часто этим пользуются, как в Индии или странах Азии. Стримы — это современная тенденция, когда видео транслируется не в записи, а онлайн, прямо здесь и сейчас. Так вот Tango Me предоставляет возможность стримить, а зрителям раздавать лайки в виде какой-то денежной компенсации. Ты можешь положить немного денежек себе на счет и раздавать их стримерам, благодаря их за то, что они делают крутой контент и рассказывают всякие классные штуки.
Tango Me — это всё еще стартап с очень долгой и интересной историей. Когда-то это была очень большая компания, которая реализовала первые видеозвонки между платформами. В то время был Skype, но он работал только между компьютерами, а в Tango были звонки с iOS на Android и на Windows и даже звонки с Windows-телефона. Потом Facebook купил WhatsApp, и Tango Мe пришлось почти умереть, но компания возродилась как феникс. И вот сейчас Tango Мe заново выросла на стриминге.
В компании я обеспечиваю надежность продакшена. Стримы должны стартовать, деньги платиться, люди логиниться. Изначально у нас не было нормального понимания, как должны стартовать стримы. Мы должны были не от клиентов узнавать, что мы «лежим», а должен был флажок загораться, а мы в это время бежать чинить поломку. Начинал я с этого. У нас не было нормальной культуры инцидентов. То есть сломалось, потом починили, и на этом всё. Зачем нужно что-то обсуждать?
В последние месяца два люди уже стали проситься на обсуждения, спрашивая, когда будет post-mortem. Практика показала, что это важно и что бизнесу от этого тоже есть польза. Я сам заполняю около 10% всех post-mortem. Вообще, заполнять его может кто угодно, но чаще это делает тот, кто больше виноват, или тот, кому это больше всех необходимо. Если кто-то виноват, это не говорит о том, что мы ругаем кого-то конкретного. Команда модерации сама заинтересована в том, чтобы ее сервис работал хорошо, поэтому, скорее всего, кто-то из ее ребят возьмется за написание post-mortem и доведение до action item.
О соломке, которую пришлось подстелить
Первые инциденты в Tango затрагивали пользователей. Сейчас такого не происходит. В 90% случаев кастомеры не замечают каких-то косяков. И так у нас уже полгода. Пользователи могут проводить стримы даже несмотря на то, что какая-то часть нашего сервиса находится в деградации. Нам нужно стабильно всё мониторить, чтобы сервис не сломался. Какие-то инциденты требуют вмешательства 10–15 человек прямо посреди ночи. Ну что ж, встаем, разбираемся и чиним.
Tango писали отцы-основатели из Калифорнии, поэтому у нас некоторая культура fallback. У нас есть две системы видео. Одна работает по UDP и пишет видео в HD 720, а вторая работает через CDN по HLS-протоколу. В Tangо они работают независимо друг от друга, поэтому если ломается одна из видеосистем, то происходит переключение на вторую. В этом случае видео будет меньшего качества, но всё продолжит работать почти незаметно для пользователя. Мы, конечно же, увидим загоревшиеся красные лампочки и побежим выяснять, что у нас произошло, почему всё упало и что именно не работает.
У нас был еще один случай. В Tango есть сервер Auth-token, который выписывает токены. Мобилки определенный токен запоминают и семь дней хранят эти данные. На этом сервере мы в марте поменяли сертификат. Сертификаты выписали новые SSL Vertigo. Оказалось, что у нас внутри мобилки своя библиотека для общения SSL, и там указаны корневые сертификаты. Получается, что она не знает, кто такой Vertigo. В итоге наши мобильные приложения перестали добираться до сервера Auth-token, потому что он для них не валидный. К счастью, у нас есть внутренний fallback, где есть запасной путь получения токена. И вот с марта наши мобильные приложения получали токен таким запасным путем.
Узнать об этом было непросто. Наше приложение иногда падало. Мы собрали crash dump, ребята из Android-команды всё починили. О том, что вообще что-то не так, мы узнали тогда, когда на сервер Auth-token пошла нагрузка. Сначала ее не было, потом она внезапно появилась. Оказалось, что у нас наконец-то заработали токены.
Про героев и волшебников
Я часто бываю на собеседованиях, вижу разных людей. Сам себе я бы нанял трех героев и четырех волшебников. А если серьезно, то я хочу видеть в команде тех людей, которым не всё равно, которые из штанов выпрыгнут, но сделают всё качественно, а не просто будут сидеть. Мне нравятся люди, которые готовы и хотят делать что-то руками.
Существует один вопрос, на который соискатели очень редко отвечают. Вопрос следующий: в Linux есть понятие Load Average, что оно означает? Причем это многие знают, но практика показывает, что мало кто это понимает. Хотя ответ на этот вопрос очень четко отображает то, насколько человек интересуется Linux и насколько глубоко знает, как внутри всё устроено. Понимание этого важно.
Мы берем либо тех людей, которые хорошо знают базу, то есть Linux и сети, либо тех, кто не очень разбирается в Linux, но хорошо знает Kubernetes и все современные облака, потому что там тоже есть свои нюансы.
История об интервью в Google
Когда я пришел в Google на позицию SRE, мне предложили выбор, кем я хочу быть: SRE-программистом или SRE-системником. Если выбрать первое, то упор будет на программирование, а если второе, то на system design и вопросы отладки Linux. Поскольку я не особо программист, я выбрал system design. Вопросы были в основном такие: у тебя есть веб-сервер, он начинает плохо работать, как ты его будешь дебажить? Оценить себя было непросто. Кстати, вопросы на собеседовании в Facebook были гораздо сложнее и глубже и касались прям «мяса» Linux.
Еще на этом интервью в Google мы считали. Мне предложили спроектировать Твиттер. Я задаю вопрос: какая надежность должна быть у нашего Твиттера? Мне говорят: «Нашему Твиттеру полагается надежность 99.99. Как ты можешь ее обеспечить?» Тогда я задаю встречный вопрос: какая надежность у нас в одной машине? Они отвечают: «У одного нашего веб-сервера надежность 90.0. Сколько тебе нужно серверов, чтобы обеспечить надежность 99.99? Давай сложим SLO, умножим всё, что нужно умножить, и посчитаем». Ребята мне дали формулу, по которой я и произвел расчет. Мы узнали пропускную способность, посчитали, что потребуется шесть машин. Но после нужно выяснить, а хватит ли шести машин, чтобы пропустить всё то, что собирается там прокачаться. Соответственно, нужно учесть, хватит ли памяти, RPS-ов. Ты знаешь входящее количество RPS-ов, тебе нужно нарисовать красивые квадратики со стрелками, то есть то, из чего будет состоять наш Твиттер.
Про поиск работы
Когда я жил в Иркутске, у меня было стойкое ощущение, что весь мир находится где-то далеко от меня. Когда я поменял в своем профиле на LinkedIn Иркутск на Москву или Минск, то мне вообще не пришлось что-то где-то искать. Раза два в неделю ко мне кто-то обращается с предложением работы. Думаю, что участие в различных митапах тоже делает мое имя чуть более известным в среде работодателей, которые потом мне пишут.
Примеры кейсов
Приведу пример про зависимость upstream, когда мы не успеваем сходить за каким-то ресурсом по запросу http-rest. Подавляющее большинство инцидентов именно с этим связано. Какой-то микросервис стал отвечать медленнее, либо отвалился. Тебе нужно поправить параметры, разобраться. Иногда мы получаем в разные моменты времени разные данные.
Еще был случай, когда кто-то где-то что-то сделал, и в итоге на базе данных сбросился автоинкремент. Мы стали выдавать всем новым зарегистрировавшимся пользователям новые ID-шники. Опасность заключалась в том, что мы могли отдать людям чьи-то аккаунты, которые уже существовали на тот момент. За то время, пока мы разбирались, 700 человек успело зарегистрироваться.
