Привет! Меня зовут Сергей Антропов.

Я занимаюсь инфраструктурой, платформами, автоматизацией и всем тем странным набором магии, который обычно называют DevOps, SRE, платформенной архитектурой и инженерией, или

«Серега, у нас прод лежит! Помоги! Спасииии!!!».

Более шестнадцати лет я работаю с серверами, сетями, виртуализацией, контейнерами, Kubernetes, Terraform, Ansible, CI/CD и прочими способами усложнить себе жизнь ради того, чтобы потом сделать её проще для остальных.

— Алоха. Меня зовут Сергей, и я DevOps инженер.
— Здравствуй, Сергей…
— И я уже три дня не деплоил в пятницу вечером.
— Отлично держишься! Проходи, присаживайся. Сегодня обсуждаем Kubernetes, CI/CD и почему “это временное решение” живет в проде уже шестой год.

Сейчас я работаю в финтехе и занимаюсь проектированием и развитием инфраструктурных платформ для больших данных.

Если говорить проще — строю системы, которые должны:

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

Хотя последний пункт индустрия пока побеждает не очень стабильно.

У нас много инфраструктуры, много автоматизации, много распределённых систем, много Kubernetes, очередей, хранилищ, мониторинга и вечной инженерной философии:

«Сейчас аккуратно оптимизируем один маленький сервис…»

А через полгода:

  • тысячи микросервисов,
  • десятки кластеров,
  • геораспределение,
  • Hadoop,
  • CEPH,
  • Kafka,
  • Livy,
  • Spark,
  • Terraform,
  • и обсуждение того, почему внезапно закончились ресурсы в дата-центре.

Мне особенно интересны:

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

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

Именно там я окончательно понял две важные вещи:

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

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

Так что да…

Eсли где-то ночью грустит Kubernetes - есть шанс, что я уже видел что-то похожее 😄

Люблю строить системы, которые:

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

Хотя, будем честны…

Без ночных логов и поиска “почему оно работало вчера” DevOps был бы слишком скучной профессией.

Немного не про инфраструктуру

Помимо инфраструктуры, я увлекаюсь всеми видами досок:
сноуборд, серф, вейкборд и прочие способы добровольно лететь лицом в воду, снег или асфальт.

Еще я фотографирую.
Иногда людей.
Иногда природу.
Иногда уставших инженеров после шестого подряд инцидента.

Фотография для меня - это хороший способ напомнить себе, что мир состоит не только из YAML-файлов, графиков Prometheus и обсуждений “почему опять не работает DNS”.

Хотя DNS, конечно, ломает жизни куда чаще, чем плохая композиция кадра.

О содержании блога

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

Большая часть материалов - это подробные HOWTO и пошаговые разборы:

  • инфраструктуры,
  • Kubernetes,
  • Linux,
  • сетей,
  • автоматизации,
  • мониторинга,
  • безопасности,
  • DevOps практик,
  • отказоустойчивости,
  • и всего того, что обычно внезапно «само перестало работать».

Я стараюсь писать так, как хотел бы читать сам:
без маркетинговой магии,
без “революционных платформ нового поколения”,
без советов уровня “просто внедрите DevOps”.

Только практика, опыт, реальные проблемы, реальные ошибки и иногда легкая инженерная истерика между строк.

Потому что любая инфраструктура рано или поздно приходит к одному и тому же состоянию:
«Кто вообще это писал?!»
А потом выясняется, что писал ты сам три года назад.

Об опыте работы

Я работал с:

  • дата-центрами,
  • облаками,
  • Kubernetes-кластерами,
  • большими объемами данных,
  • CI/CD,
  • платформенной инженерией,
  • мониторингом,
  • безопасностью,
  • автоматизацией,
  • и командами, которые сначала говорят: «Да тут маленький сервис», а через полгода у тебя уже двадцать микросервисов, очередь сообщений, GPU, Kafka и психологическая травма.

Мне интересны:

  • сложные инфраструктурные задачи,
  • высоконагруженные системы,
  • платформы,
  • архитектура,
  • отказоустойчивость,
  • DevSecOps,
  • SRE,
  • автоматизация всего, что можно автоматизировать,
  • и попытки объяснить бизнесу, почему “один Вася-админ” больше не справляется.

Если хотите предложить что-то интересное - пишите: work@antropoff.ru

Условия использования

Все материалы этого уютного инженерного бложека распространяются по лицензии Creative Commons - «Attribution-ShareAlike» («Атрибуция - На тех же условиях») 4.0 Всемирная - CC BY-SA 4.0.

Вы можете:

  • копировать,
  • распространять,
  • адаптировать,
  • изменять,
  • использовать материалы в коммерческих и некоммерческих целях.

Проще говоря - берите, пользуйтесь, развивайте.
Только не забывайте указывать источник.

Отказ от ответственности

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

Материалы публикуются по принципу:
«КАК ЕСТЬ» (AS IS).

Это означает:
если после выполнения команды из статьи у вас:

  • упал прод,
  • сломался Kubernetes,
  • исчезла сеть,
  • перестал отвечать Ceph,
  • или сервер внезапно решил уйти в отпуск

то, пожалуйста, сначала проверьте:

  1. что вы вообще запускали;
  2. на каком сервере;
  3. и почему делали это в пятницу вечером.

Адекватно оценивайте свои возможности.
И помните главное правило инфраструктурного инженера:

Нет ничего более постоянного, чем временное решение, которое “пока просто работает”.

Кстати, вот мой сайт - там обо мне подробнее: https://antropoff.ru