Был сисадмином, затем техническим директором — стал DevOps-тимлидом. В идеальном мире моя задача — автоматизировать рутину, настроить CI/CD, мониторинг и придерживаться принципа “Инфраструктура как код”.
Но это в теории. На практике же стабильность системы держится на честном слове, пока кто-то не решит "чуть-чуть поправить" прод. Поэтому DevOps — это вечный "День Радио" в отдельно взятой инфраструктуре.
“День Радио” — это фильм с сюжетом, что в прямом эфире вот-вот должен стартовать марафон, но за десять минут до начала выясняется, что заранее подготовленная тема перехвачена конкурентами. И начинается суета и множество сюжетных поворотов и проблем 🙂
Ранним утром понедельника, когда солнечные лучи ещё не дребезжат на горизонте, когда город за окном только-только начинает оживать, и на улицах появляются первые люди, спешащие на работу на другой конец города, я уже за работой. Вместо трелей будильника мой телефон издает тревожный звон сообщений из системы мониторинга и экстренных звонков от клиента.
Ещё даже не проснувшись, но уже общаясь с клиентом, одним глазом смотрю в отчеты системы оповещений и вижу, что сломалась база данных. В такой ранний час из кластера предательски вывалилась одна нода. Все так же в режиме "автопилота", машинально копирую выжимку логов сервера, для ознакомления с ними позже и принятия мер по недопущению досадного инцидента в будущем, а затем применяю стандартный набор инструментов восстановления.
Инициализировав новую ноду и добавив ее в кластер, я заботливо отписываюсь клиенту, что работа системы будет восстановлена в ближайшее время и только после этого укладываюсь обратно в кровать, чтобы урвать драгоценные оставшиеся минуты сна..
“Подъем по тревоге” ночью или в выходные происходит не часто (один-два раза в месяц). Только если отваливается проект, по которому ответственный я, или кто-то из инженеров моей группы, который не смог принять вызов.
Как и у многих хостинговых компаний на рынке, у нас сложилась “многоярусная” система реагирования на проблемы с инфраструктурой. Первый уровень - это младшие дежурные, которые сидят посменно: по 12 часов в режиме 24/7. Когда-то и я начинал с такого, но в другой компании.
Мы сознательно отказались от полностью автоматической системы и поставили между инфраструктурой и инженерами людей. Автоматика бы отзванивалась на любой чих в системе. А задача младших дежурных - провести первичный аудит проблемы, т.е. подтвердить, что она действительно требует решения, это не ложное срабатывание.
Если проблема не отсеивается и не решается на нижнем уровне, младший дежурный звонит инженеру. У каждого инженера есть набор проектов, по которым к нему могут обратиться круглосуточно. Плюс, в компании предусмотрена система эскалации — если инженер недоступен, звонок поступает вышестоящему коллеге — в первую очередь мне, как лиду. Если бы и я не снял трубку, звонок пошел бы техническому директору.
Сегодня инженер, ответственный за проект, не подошел к телефону, но цепочка остановилась на мне.
10:00. Утренний скрам
Штатный подъем — тремя часами позже. Умываюсь и иду на дейлик в 10:00 по Москве, где мы отчитываемся о наших задачах. Как правило, по задачам у нас две встречи: ровно в десять мы отчитываемся, что делали вчера — в данном случае в пятницу, что произошло за выходные, что будем делать сегодня и в какой последовательности.
Эта встреча помогает правильно расставить приоритеты. Обязательно присутствуют проджекты, которые приносят обратную связь от заказчиков - допустим, клиент приходил в пятницу и просил побыстрее что-то сделать. Мы оцениваем срочность и, если это необходимо, раздвигаем очередь задач, чтобы сфокусироваться на самом важном.
Стараемся быть предельно краткими — ничего не обсуждаем, просто ставим приоритеты и синхронизируем статусы. В общей сложности на опрос 20 с лишним человек уходит 18-20 минут.
10:20. Разбор полетов
Следом проходит After scrum, где мы уже устраиваем разбор полетов. Тема сегодняшнего утра - почему подъем по тревоге был у меня, а не у ответственного инженера. Как выяснилось, тот поставил телефон на зарядку в соседней комнате и не услышал звонка. Обсудили ситуацию, договорились больше так не делать.
В целом в подобных ситуациях мы друг на друга не обижаемся. У нас сыгранная команда и доброжелательные отношения. В данном случае было бы гораздо хуже, если бы я был недостаточно знаком с проектом. В подобных случаях понять даже самые простые вещи спросонья не так-то просто.
На After scrum мы обсуждаем не только инциденты, но и то, кому и как решать те или иные задачи. Младшие приходят к старшим, а я часто выступаю эдаким “играющим тренером” - раздаю ребятам задачки, принимаю результаты работы и даю подсказки, наводящие на решения возникающих трудностей.
Чаще всего, кстати, при приемке срабатывает проверка “на дурака” - что в задаче действительно выполнены все пункты, именно так, как просил клиент, а не как додумал DevOps-инженер. В анализе задач всегда приходится включать здравый смысл. В нашей сфере задача вполне может быть решена (допустим, попросили добавить какой-то флаг PHP — ты добавил), а проблема клиента — нет. Это частая история. Иногда даже приходится применять решение, противоречащее best practice, потому что именно оно, а не что-то другое, решает задачу клиента.
11:00. Архитектурный созвон
Расходимся мы около 11 часов. После этого по понедельникам я созваниваюсь с архитекторами — это 3-4 человека по всей команде. Зачастую присутствуют и проджекты, которые ведут данные проекты.
У нас около 30 проектов — больше, чем у других команд в компании. На созвоне проджекты называют их по алфавиту, а мы обсуждаем, что в них произошло за последнюю неделю. У кого-то не происходило ничего, где-то мы отчитались о последних выполненных работах, но клиент с обратной связью не вернулся, у кого-то были инциденты, и мы их починили, и так далее. Событий много, так что и времени на эти обсуждения уходит прилично — до полутора часов.
В другие дни недели вместо архитектурной встречи у меня есть час или два свободного времени, чтобы решить свои задачи.
12:30. Анализ логов
После окончания созвона выдался момент, чтобы наконец проанализировать, что произошло рано утром. Нужно не только понять, что вызвало падение ноды, но и написать отчет клиенту — его, как правило, пишет инженер, который обработал инцидент, т.е. я.
Скорее всего роль сыграли изменения от разработки клиента. Моя задача: описать случившееся и отчитаться об общем даунтайме, если он был. Сегодня инцидент имел место, но система просто перешла в режим деградации, на продукте это никак не сказалось. Готовый отчет я направляю разработчику, который ведет проект со стороны клиента, а также прикладываю к задаче в нашем таск-трекере (в зависимости от того, каким инструментом пользуется клиент).
Как правило, инцидент — это проблемная область с определенными симптомами, если говорить терминами управления. Так что я не только отчитываюсь письменно, но и созваниваюсь с клиентом, чтобы выяснить, как я могу помочь решить эту проблему на системном уровне, чтобы повторно таких событий не возникало.
По итогам всех изысканий мы выстраиваем цепочку гипотез и подтверждений. И если знаем, куда копать, идем решать - проверяем гипотезы одну за другой, пока не доходим до проблемной точки. В зависимости от поломки, эта история может растянуться на неделю и больше, хотя, если кейс простой, все решается за пару часов.
Сегодня у меня не было свободного окна между встречами, поэтому обед пришлось поглощать за компьютером. В короткой паузе между созвонами сходил на кухню, поцеловал жену в щечку, залез в холодильник и достал уже готовый обед — сегодня это ежики. Разогрел в микроволновке, пошел обратно на свое рабочее место.
14:00. Ворох задач
Послеобеденное время — период, когда можно тет-а-тет обсудить задачи коллег. Сегодня, например, минут 40 проводил плановый performance-аудит баз данных одного из проектов. Потом отвечал на вопросе в чате пресейлов.
Помимо встреч, мне с разных сторон прилетают задачки. Например, приходят коллеги из отдела маркетинга с заявками от клиентов. Они ждут совета, как и в какой пакет обернуть требуемую услугу, какую сделать презентацию. Будучи архитектором, я также занимаюсь планированием различных работ и разбором уже выполненных операций перед тем, как они будут сданы клиенту. А еще с каждым из клиентов у меня есть еженедельный созвон по событиям за эту неделю. Могу так же, как инженер, сделать какие-то задачи из общего трекера: сегодня я переделал раннеры в GitLab CI, достал данные из логов по просьбе коллеги, ответил на вопросы в чате разработчиков.
В своей работе мы в основном опираемся на подход инфраструктура как код (Iaac). Основные инструменты — Ansible и Terraform, так что 80% времени мы работаем с заготовками Ansible. У нас есть копилка плейбуков для Ansible, которые модифицируются всеми командами. Это общий котел с заготовками, откуда мы периодически вынимаем и добавляем нужное. Но вопросы в чате все равно возникают часто.
Иногда дело доходит и до собеседований. Как именно я собеседую — на что и почему смотрю — я расскажу отдельно. Это довольно обширная тема.
В таком потоке задач приходится постоянно помнить о приоритизации. Высшую важность для меня имеют задачи, связанные с поломками или то, что нужно выполнить строго по дедлайну. Следующий уровень — пресейлы. Также стараюсь максимально быстро делать задачи от коллег из других отделов, чтобы не держать коллег в ожидании - чтобы они могли пойти дальше общаться с клиентом.
19:00. Вечер трудного дня
Мой рабочий день заканчивается в 19 часов. Под конец дня я заполняю отчет, куда потратил свое время - мы трекаем все в Redmine. После этого иду к техдиру и спрашиваю в переписке, как прошел день, какие есть проблемы, не нужно ли что-то подхватить. Делаю я это уже обычно с телефона, сидя на кухне. С техдиром мы в свободной форме обсуждаем ситуацию и расходимся отдыхать.
Кажется, что мой график не нормирован. Но на самом деле это только одна сторона медали. Вторая сторона, что я могу работать всего 4 часа за день. У нас свободное отношение к присутствию на рабочем месте (если не случился инцидент, конечно). Надо жену в магазин отвезти посреди дня — пожалуйста. В МФЦ документы подать — тоже без проблем.
Понедельник у меня довольно насыщен работой. Во вторник и четверг вечером после окончания рабочих дел я собираю сумку и иду в спортзал, чтобы покрутить педали и отдохнуть в парилке. После нее кажется, что жизнь удалась!
Вне дома я люблю слушать аудиокниги. В последнее время мне нравится "боярка". Порой книги настолько увлекают, что я даже пытаюсь растянуть дорогу на машине, чтобы послушать подольше. Сейчас слушаю “Идеальный мир для лекаря”.
Вечером, уже дома, могу посмотреть кино с женой или сажусь за свой пет-проект. Просто изучать технологии мне уже не так неинтересно, а под конкретную задачу — вполне. В рамках пет-проекта я собираю опенсорсный сервис мониторинга — эдакий “швейцарский нож” девопсов. Пытаюсь найти для него кирпичики: смотрю чужие проекты и сервисы, экспериментирую с ними. Там бывают интересные задачки — можно случайно залипнуть и “очнуться” в 3 часа ночи, понимая, что уже как 3 часа ты должен спать =D.
День подошел к концу. Завтра снова буду следить за инфраструктурой и чинить возникающие поломки, чтобы сделать разработчиков наших клиентов чуть более счастливыми.
Хочу запросить обратную связь у коллег-айтишников. Что интересного у вас в течение дня происходит?
