Ответ на пост «Про инженеров на стройке»⁠⁠25

Увидел пост коллеги-ПТОшника про стройку и зацепило. Ведь действительно была на Пикабу славная традиция рассказывать про свою работу изнутри. Без ужасов, без пафоса, просто "а вот так у нас устроено". Подхвачу эстафету.

Работаю директором департамента облачной инфраструктуры и DevOps в банке. Управляю командой из 7 инженеров и более чем 50 системами.

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

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

Из интересного у нас есть несколько штук, про которые обычно никто не знает.

Kubernetes (читается "кубернетес", а между собой зовём просто "кубер").
Это такая штука, которая запускает сотни мелких программок на десятках серверов и следит, чтобы каждая была жива. Если сервер сдох - программки автоматически переезжают на живые. Если нагрузка выросла - запускается больше копий. Если упала - лишние гасятся. По сути диспетчер, который в реальном времени жонглирует контейнерами с кодом, как повар сковородками. У нас таких кластеров несколько, в них живут много различных банковских систем.

Дежурства (on-call).
Один инженер на неделю берёт на себя телефон, который звонит, если что-то сломалось. Звонить может и в 3 ночи, и в субботу, и когда ты в душе. Банк работает 24/7, значит, и мы должны быть готовы 24/7. Так что если вы когда-то успешно перевели деньги ночью - знайте, что там был живой человек, который в этот момент не спал "на всякий случай".

Постмортемы.
Звучит медицински, а на деле - разбор полётов после инцидента. Что-то сломалось - пишем подробный документ: что случилось, почему, что делали, сколько времени ушло, и что изменить, чтобы не повторилось. Цель не найти и наказать виноватого, а починить систему так, чтобы она сама больше не давала такому произойти. Культура называется blameless - без поиска виновных. Потому что если бить за ошибки, инженеры просто начнут их прятать, а это в сто раз хуже.

SLA (Service Level Agreement).
Обещание, что система работает определённый процент времени. Например, 99.95% аптайм - звучит красиво, а по факту это разрешение простоять всего 4 часа 22 минуты в год. Четыре часа. В год. Вокруг этой цифры крутятся все планы обновлений, все ночные работы, все нервные совещания. И когда вы видите в новостях "крупный банк лежал два часа" - знайте, что где-то в этот момент инженеры уже прощались с годовым SLA.

И напоследок - куда девается "свободное время" у инженера инфраструктуры.

У меня дома четыре кошки, собака, жена, мама и дед. В прошлом году у одной из кошек, Манишки, нашли диабет. Сел на пару выходных и собрал для неё PWA-приложение - вести сахара, инъекции и анализы нормально. Назвал diabnostic.ru. Неожиданно выстрелило, подключились ветклиники, Манишка в ремиссии. Но это уже отдельная история - есть серия постов у меня в профиле, не буду здесь дублировать.

Оказалось, инженер инфраструктуры - это не только про то, что работает снаружи. Это ещё и про то, что сам себе на коленке за выходные поднял платформу, лишь бы удобно было вести здоровье кота.

Поддерживаю эстафету коллеги. Пишите про свою работу — реально интересно читать.
Если вдруг захотите поддержать мой проект - буду очень благодарен.

Или же есть вопросы по моей профессии - тоже не стесняйтесь задавать, отвечу =)