Посты

Милые существа вокруг.

Пока:
не намочишь;
не покормишь после полуночи;
не нарушишь правила.

— Да там маленькое изменение.

В пятницу.
После полуночи.

Современное АйТи решает задачи,
которые вчера казались невозможными.

Мир растёт, нагрузки растут.
Всё, что вчера казалось неподъёмным,
сегодня — рутинная операция.

QR-код в SSH-терминале.
На другом континенте.

Для авторизации пользователя.

Работает.

К этому уже привыкли.

Как-то подходит архитектор:

— Тут есть VM, которые давно никто не использует. Давай удалим. Например, dev-стенд команды, которая ушла пару лет назад.

11:57 — выключили.

12:00 — обед.

12:13 — звонок:

— У нас час пик. Всё встало. Очереди.

12:20 — включаем.

12:21 — сервис восстановлен.

Root cause: Часть интеграций обращалась к dev среде.

Impact:

Решилась одна загадка — почему багфиксы ничего не меняли.

На тестах — всё хорошо. И на «прод стенде» — тоже.

Гонка, где скорость — только часть задачи.
Доехать быстро — мало.

Утро встречают другие.

У финишной черты.

Почему все так боятся пятницы?

За годы эксплуатации заметил странную вещь.

В ИТ пятница давно стала религией.

«В пятницу релизы не делаем»

«После обеда ничего не трогаем»

«Кто катит в пятницу — сам потом и дежурит»

Логика понятна.

Что-то сломается, кто-то останется ночью, а кто-то будет искать того самого инженера, который «точно знает как это работает».

Иногда — уже в субботу.

Но есть один неудобный вопрос.

Почему пятница?

Система знает, какой сегодня день недели?

Если релиз в пятницу опаснее релиза во вторник — проблема не в календаре.

Обычно всё скучнее.

Rollback есть.
Но спокойствия это не добавляет.

Мониторинг зелёный, пока клиент уже пишет, что всё плохо.

Тестирование было.
Но уверенности в изменениях мало.

Радиус проблем становится понятен уже после релиза.

Тогда да.

В пятницу лучше ничего не трогать.

Потому что иногда последствия становятся заметны только в понедельник.

Вместе с потерянными клиентами.

И такое бывало.

А иногда всё работает иначе.

Изменение выкатывается спокойно.

Ошибка остаётся локальной.

Инженер спокойно уходит отдыхать.

И релиз перестаёт зависеть от того, ответит ли в субботу тот самый парень в футболке.

Тогда пятница снова становится просто днём недели.

Бояться обычно стоит чего-то другого.

Люблю аркадные игры 70–80-х.

Как инженерную работу.

Сделать нечто интересное в очень ограниченных условиях — отдельное ремесло.

Памяти мало.
Процессор слабый.
Несколько цветов на экране.
И при этом — лучшая графика своего времени.

Люди стояли в очередях к автоматам.

Никаких патчей.
Никакого «доделаем потом».

Нужно сразу сделать механику, которая работает.
И работает так, что спустя 30–40 лет в это всё ещё играют.

Сейчас местами даже сложно понять — как они это вообще сделали.

И играть в это до сих пор сложно.
Аркады плохо умели жалеть игрока.
Потому что хорошо сделано.

Честная механика.
Честная сложность.

И ведь местами это были просто игры.

А потом вокруг них вырастало новое железо.
Новые возможности.
И новые ограничения.

Забавно.

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

Eject Coin

Свет.
Музыка.

Ночной инцидент.
Вместо ночного кофе — отвлекаться на работу.

После устранения аварий понимаешь:

Надёжность — не для бизнеса.
Не для пользователей.

Ночью лучше спать.
И лучше не одному.

_«Moscow Calling»_

Были революционные профессии.

Эксперт по вводу информации в компьютер.
FoxPro.
Человек-сканер.
Распознавание текста в реальном времени.
Десятки записей за день.
Ручная работа.
Клавиатура стучит.

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

Открывайте connection к базе.

И не спешите.

Сначала собирайте данные.

Потом ещё данные.

Что-нибудь посчитайте.

Куда-нибудь отправьте.

И только потом закрывайте connection.

И так каждый request.

Особенно интересно потом слышать:

«что-то highload не получается»

Тишина.

Любовь — это принимать любые недостатки.

Зимой на KuBeer Talks я выступал с докладом:

«Почему вам не нужен Kubernetes»

После выступления несколько человек подошли примерно с одинаковым вопросом:

«Ты серьёзно считаешь, что Kubernetes не нужен?»

Kubernetes за последние годы стал для индустрии ответом по умолчанию. Проект только стартует, требования ещё меняются, команда небольшая. В архитектуре уже появляются ingress, service mesh, Helm, GitOps, мониторинг, централизованное логирование — современная инженерная молитва.

Вокруг проектов уровня:

«обычный интернет-портал»

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

Условный «привет, мир» с формой заявки и нагрузкой:

«два человека в праздники»

Зачем?

Ответ обычно простой:

«так сейчас делают»

Цена обычно приходит позже — когда кластер начинает жить собственной жизнью, обновление неожиданно ломает работающую систему, а команда понимает:

Kubernetes — это уже отдельный пласт постоянной работы.

Обычно это выясняется во время инцидента. Или в момент, когда оказывается, что Kubernetes в компании по-настоящему понимают полтора человека.

Доклад в целом был про простую вещь:

технология должна соответствовать задаче и команде.

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

Иногда это напоминает попытку завести 300-килограммовую гориллу в маленькую квартиру.

Завести получилось.

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

Особенно интересно это выглядит в небольших компаниях: несколько разработчиков, планы, диаграммы Ганта, встречи про скорость разработки.

Всё это в итоге держит один парень в футболке из Омска, которому теперь ещё и Kubernetes сопровождать.

За 20+ лет эксплуатации я увидел простую закономерность:

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

Иногда достаточно Docker Compose, Nomad, PaaS, managed Kubernetes или обычной VM.

В итоге всё обычно сводится к довольно скучным вопросам:

работает ли система
выдерживает ли нагрузку
умеет ли команда её поддерживать
придётся ли кому-то чинить всё это ночью

Ночами, если честно, лучше спать.

Для тех, кто любит спорить аргументированно — приложил презентацию с KuBeer Talks.