Вредные советы: Почему не нужно писать документацию к IT-системам

Совет первый: Всё и так понятно
Не пишите документацию — код сам себя объясняет! Зачем тратить время на описание того, что и так очевидно? Переменная tmp_var_2 явно означает временную переменную номер два. А функция doStuff() делает всякие штуки. Что тут непонятного?

Совет второй: Держите знания при себе
Документация — это способ поделиться знаниями, а зачем? Лучше быть незаменимым! Пусть только вы знаете, как работает критически важная система. Так вас точно не уволят, и отпуск брать не придётся — кто же без вас справится?

Совет третий: Экономьте время
Зачем тратить драгоценные часы на написание документации, когда можно написать ещё пару функций? Документация не приносит прибыли! А то, что новый сотрудник три недели разбирается в вашем коде — это его проблемы, пусть учится методом проб и ошибок.

Совет четвёртый: Документация устаревает
Не пишите документацию, потому что она всё равно устареет! Зачем создавать то, что завтра станет неактуальным? Лучше оставить код без объяснений — он хотя бы не врёт о своём назначении.

Совет пятый: Полагайтесь на память
Зачем записывать конфигурацию серверов и процедуры развёртывания? У вас же отличная память! Правда, через полгода вы забудете, зачем нужна эта странная строчка в конфиге, но это придаст работе элемент загадочности.

Совет шестой: Пусть система говорит сама за себя
Не документируйте архитектуру — пусть новые разработчики изучают её по логам ошибок! Это же так романтично: как археологи восстанавливают историю по черепкам, так и программисты восстановят логику по stack trace.

Совет седьмой: Избегайте комментариев
Комментарии в коде — признак слабости! Настоящий программист пишет код, который не нуждается в объяснениях. А если коллега не может понять вашу гениальную однострочку из 200 символов, то проблема в нём, а не в вас.

Совет восьмой: Пароли в голове
Не записывайте пароли и доступы — держите их в памяти! Это же так удобно: только вы знаете пароль от продакшена, значит, только вы можете его починить в 3 утра в воскресенье.

Следуя этим простым советам, вы гарантированно создадите IT-инфраструктуру, которая будет работать исключительно благодаря магии и вашему личному присутствию. Ваши коллеги будут в восторге от возможности разгадывать загадки вашего кода, а руководство — от стабильности системы, зависящей от одного человека.

Что здесь может быть плохого, ведь амазон не берет деньги за записи iam?
Да, не берет.
Это бесплатно.

Дороговизна проявляется, когда кто-то из этих пользователей поделится паролем или ключами с кем-то, кому интересно, и этот кто-то зайдет в гости.

Это даже не вопрос лояльности вашего бышего сотрудника.
Хотя, какая лояльность от сотрудника, который уволился 8 лет назад?
Это вопрос статистики.
126 пользователей, из них всего около 10, пусть 20 активных (а им доступ-то нужен туда вообще?)
итого, 100 потенциальных точек неавторизованного доступа.

Сколько стоит конфиденциальность вашей информации в AWS? Сколько вам будет стоить потеря этой информации? Просто информации.
Потеря настроенной инфраструктуры?
Сколько вам будет стоить времени и денег восстановить эту информацию и настроенные компоненты вашего бизнеса?

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

При этом просто обязательное включение mfa может предотвратить 80% атак.
Банальная гигиена информационной безопасности - не пренебрегайте ею.

Вобщем, очередной клиент, у него пачка отдельных aws аккаунтов. Все работает, все норм.
Говорит - чет мне кажется, расходы велики, надо проверить. Посмотри.

Смотрю.
Первые пять секунд, я просто взял список расходов из биллинга и прочитал.
26 ip-адресов, которые арендованы у амазона и не используются.
Elastic IP, они это называют.

Раньше у амазона была фишка, что если eip арендован и используется, то есть привязан к какому-то сервису, например, виртуалка (ec2 instance), или vpn endpoint - то он бесплатен.
Если он выделен, но не привязан - то за это берется плата $0.005/час. Это примерно $3.5 в месяц.
С 1 февраля 2024 плата берется за любой eip адрес, даже если он используется.
Но в биллинге это разделение осталось, что очень удобно при аудите - просто смотришь строчку "Idle eip" и сумму.

Собственно, это то что я увидел в первые 10 минут анализа, из которых 5 было потрачено на логин и еще 4 на получение этой выписки.

26 неиспользуемых адресов по $3.5/месяц - это $91/месяц. В год получается $1092.
Так если подумать - это немного.
Ну серьезно, у них счет ежемесячный в амазоне - примерно $4000. В месяц. То есть, $48000 в год.
Вот эти адреса стоили чуть больше двух процентов их расходов.
88 тысяч рублей за год из почти четырех миллионов.

Похоже на небольшую комиссию за перевод. Ладно, большую комиссию.

Но.
Вот серьезно, они это платили три года (тогда были удалены сервисы, с которыми они использовались).
Я за то что сделал аудит их небольших аккаунтов взял как раз примерно эту стоимость.
Мои услуги по факту для них стали бесплатными.
Они окупились в тот же день.
Просто потому, что я взял их счет и посмотрел.

Остальное там было не столь быстро, пришлось по каждому сомнительному пункту уточнять, вроде "а вот эти виртуалки, они вам зачем? Их метрики нулевые, трафика нет...".
В итоге наскоблили примерно на $400 в месяц.

Снизить расходы на 10% за одну неделю. Стоило ли это того?

Клиент доволен, для него это окупилось. Я доволен, я получил свою оплату и могу вам рассказать еще одну историю.

Как потерять три часа истории мониторинга из-за одной циферки в конфиге

Знаете, что самое обидное в IT? Когда все вроде бы сделано правильно, но в критический момент система подводит. И оказывается, что проблема была в одной настройке, о которой просто забыли.

Что случилось

Делали клиенту страницу статуса сервиса — чтобы всегда видеть, работает ли все как надо. Поставили мониторинг на две отдельные машины (ноды), настроили так, чтобы они обновлялись по очереди. Казалось бы, запас надежности есть.

Но в воскресенье ночью система обновила одну из нод, и... трех часов истории как не бывало. Сервис работал, но данные мониторинга просто исчезли на это время.

В чем была ошибка?

Представьте: у вас два сейфа для хранения важных документов. Вы думаете: "Отлично, есть резервирование!" Но все документы лежат только в одном сейфе. Второй — просто пустой, на всякий случай.

Именно это и произошло. Машин для мониторинга — две. А сам сервис, который собирает данные, запущен только на одной из них. Причем в одном экземпляре.

Когда система начала обновление этой ноды, она просто вышвырнула сервис и начала запускать новую версию. А запуск занял три часа. Почему так долго — отдельная история, но суть не в этом.

Что делают неправильно?

Можно было настроить систему так, чтобы она не давала отключить последнюю копию сервиса. Это называется PodDisruptionBudget — такая защита от дурака.

Но у нас его вообще не было. Поэтому система просто взяла и выключила единственный экземпляр.

А если бы мы его настроили неправильно — выставили минимум в 1 работающую копию при общем лимите в 1 копию — было бы еще хуже. Система не может запустить новую копию (лимит 1, а одна уже работает) и не может удалить старую (PDB требует минимум 1). Получается тупик, и обновление кластера просто зависнет навсегда.

Как правильно?

Всё просто: если сервис критичный — запускайте минимум две копии. Даже если по нагрузке хватает одной. Это и есть настоящая отказоустойчивость.

Плюс включайте эту самую защиту (PodDisruptionBudget). Тогда система не выключит последнюю работающую копию, пока не поднимется новая. Да, обновление кластера может затянуться. Но зато без простоев.

Мораль

Владельцы бизнеса часто думают: "Ну у меня же две машины, все должно работать надежно!" А на деле оказывается, что само приложение запущено в одном экземпляре, и никакие две машины не спасут.

Вот и получается: деньги потрачены на "надежность", а в критический момент — три часа пробела в мониторинге. А если бы это был не мониторинг, а основной сервис?

А у вас в проде сколько реплик у критичных сервисов? Один — это не отказоустойчивость, это надежда.

"В чём разница между арендовать сервер в интернете и сделать облачное приложение?"

Представь: ты можешь взять грузовик в долгосрочную аренду — он твой, пока платишь, но ты сам его заправляешь, чинишь, планируешь маршруты, нанимаешь водителя.
Сломался в дороге? Твоя проблема. Нужно везти больше груза? Арендуй второй грузовик, сам разбирайся как распределить товары между ними.

А можешь подключиться к логистической платформе: указал пункт А и Б, объём груза — система сама подобрала нужное количество машин, распределила маршруты, подключила резервный транспорт на случай поломки.
Вырос объём поставок? Платформа автоматически добавит грузовики. Один сломался? Другой уже подъехал, ты даже не заметил.

АРЕНДОВАТЬ СЕРВЕР (VPS, Dedicated) — это взять "грузовик". Ты получаешь машину с фиксированными ресурсами: 4 ядра CPU, 16 GB RAM, IP-адрес. Запускаешь всё сам — сервис, nginx, базу данных, настройки безопасности. Если нагрузка выросла в 10 раз, ты вручную поднимаешь второй сервер, настраиваешь балансировщик, синхронизируешь данные. Упал сервер ночью? Пока ты не вмешаешься, приложение недоступно.

ОБЛАЧНОЕ ПРИЛОЖЕНИЕ — это когда ты используешь управляемые сервисы провайдера (AWS ECS, Lambda, RDS, ALB).
Твой код запускается в контейнерах, которые автоматически масштабируются под нагрузку — от 1 до 100 или 1000 инстансов за минуты. База данных реплицируется, бэкапы создаются. Балансировщик распределяет трафик и отсекает упавшие инстансы. Ты строишь архитектуру, а платформа обеспечивает высокую доступность и отказоустойчивость.

Разница не в том, ГДЕ крутится код, а в том, КТО отвечает за масштабирование, надёжность и доступность.

Реальный кейс: компания просит "запустить Django API в AWS".
Я делаю ECS + ALB + автоскейлинг + Multi-AZ.
Выясняется — им нужен просто один EC2 с HTTP на порту 8000 для разработки. Это не облачное приложение, это арендованный сервер в AWS. Переплата в 5 раз по сравнению с VPS в Hetzner за €5, а преимуществ облака — ноль.

Задайте мне вопрос по теме — и я вам отвечу

Привет! Я тот человек, который следит, чтобы ваша облачная ИТ-инфраструктура работала, а не пожирала деньги.

Некоторое время назад я работал с одной компанией. Они предложили мне 25 евро в час вместо 35, мотивируя это тем, что "клиенты платят им меньше". Без фиксированной оплаты. То есть, есть задачи — я работаю, нет задач — сижу без оплаты. При этом на бюрократию уходило столько времени, что я фактически работал почти бесплатно.

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

Теперь я делаю по-другому. Провожу аудит, показываю что не так, объясняю что можно сделать лучше — и почему это важно для вашего бизнеса. Не просто "этот сервер быстрее", а "в этом случае вырастет стабильность приложения, улучшится SLA, и в итоге будет дешевле". Я говорю на языке денег и результата, а не только технологий.

Я верю: ИТ-инфраструктура нужна не сама по себе. Она нужна, чтобы бизнес работал без сбоев и приносил прибыль. А облако — это не волшебная кнопка "сделать всё лучше". Это инструмент, который нужно правильно настроить.

Чем я могу вам помочь:
— Аудит инфраструктуры: найду узкие места, покажу где переплачиваете, что мешает расти
— Консультации: регулярный ревьюер для команды, кто-то с большим опытом, кому можно задать вопрос
— Реализация: помогу воплотить проект после консультации

Если у вас есть ощущение "что-то работает не так" или "платим много, а толку мало" — напишите в ЛС. Обсудим вашу ситуацию по-человечески, конкретно, подробно.

Я редко делюсь своими фейлами. Но за 15 лет в IT-инфраструктуре я понял: самые дорогие и ценные уроки — из собственных ошибок. Хотя, гораздо выгоднее всё-таки учиться на чужих. Вот одна из моих.

Это было в самом начале моей карьеры. Мне дали задачу: удалить несколько строк из таблицы базы данных. На проде. Прямо в консоли. Почему сразу на проде? Сейчас уже не помню. Помню только, что я только-только разобрался, как вообще запускать команды, на примере SELECT.

Я должен был написать:

DELETE FROM users WHERE is_active = false;

Я написал:

DELETE FROM users;

Секунда. Консоль показала: "Удалено столько-то строк". Я офигел. Сделал SELECT - 0 результатов. Таблица пустая.

Секунд 10 я сидел и думал: "Как это исправить?". И понял — лично я ничего не могу. Тем более быстро. Мыслей типа "меня уволят" не было. Была только одна: исправить всё как можно быстрее.

Я пошёл к сеньёру, который мне поручил это. Рассказал что случилось.

Он был спокоен. Реально не парился. Быстро проверил, что бэкап был сделан сегодня и успешно завершился. Сказал: "А, ну щас поправим. База не особо активная на изменения, бэкап свежий, всё норм".

Я не следил за временем — я смотрел, как он восстанавливает данные, чтобы запомнить каждый шаг. Через 15 минут всё было на месте. Ничего не потеряли.

---

Что я понял тогда?

Во-первых, бэкапы — это не опция. Они нужны всегда и для всего. Причём не просто "есть где-то", а регулярные, целые, проверенные. Ты должен знать, что из них можно восстановить данные — не теоретически, а реально.

Во-вторых, ручные изменения на проде — это зло. Особенно если их поручают джуну без присмотра и контроля. Особенно если не отработали это на тестовом окружении.

С тех пор я пишу скрипты. Перепроверяю их на тестовых средах. Использую dry-run, если это в принципе возможно. Стремлюсь к максимальной автоматизации. Применяю атомарные операции — если что-то в цепочке команд упало, откатываются все изменения.

Теперь я слежу, чтобы доступ в прод был только у тех, кому реально надо, а все изменения проходили ревью. Я показываю джунам, как работать на тестовых средах, отрабатываем процессы вместе. А на прод руками всё равно не лезем, если можно иначе.

---

Если ты сейчас в похожей ситуации — знай:

Ошибки случаются. Даже у тех, кто делает это 10 лет. Разница в том, есть ли у тебя система, которая позволяет откатить последствия быстро и без паники.

Бэкапы, тестовые окружения, автоматизация, ревью — это не перфекционизм. Это страховка.

А ещё — если ты джун и накосячил: иди сразу к тому, кто может помочь. Не сиди в панике. Чем быстрее скажешь — тем быстрее исправите.

И да, нормальные сеньёры не уволят тебя за такое. Потому что когда делегируешь — ты должен быть готов, что человек ошибётся. Его обучение, в том числе на косяках — это цена за то, что он будет делать работу вместо тебя.

Платите за каждый Load Balancer в GCP? Есть способ урезать счёт

Представьте: у вас 10 микросервисов в GKE. Для каждого поднят свой Application Load Balancer. Это значит 10 внешних IP-адресов. Казалось бы, мелочь — но когда сервисов становится 20, 30... счёт за IP начинает бросаться в глаза.

В чём суть проблемы?

GCP берёт деньги за внешние статические IP ($0.01/час = ~$7/месяц за каждый). Когда у вас 10 IP - это $72/месяц. Запустили ещё 10 сервисов — уже $144. Плюс управление: отслеживать DNS-записи для каждого IP, следить за сертификатами, дебажить routing. Это не космос, но больно.

Что делают неправильно?

Классическая ошибка — "один сервис = один Load Balancer". Так проще на старте, но дальше это превращается в зоопарк из IP-адресов и конфигов. Второй миф: "SSL-сертификаты дорогие, надо экономить". В GCP managed-сертификаты для HTTPS бесплатны (первые 100 штук). Проблема не в сертификатах, а в IP.

Как правильно?

Можно использовать один Application Load Balancer как прокси (аналог Nginx). Несколько доменов (service1.example.com, service2.example.com) висят на одном внешнем IP. Load Balancer по host header понимает, куда отправить запрос, и автоматом управляет SSL-сертификатами для всех доменов.

В GCP ALB оплата идёт за routing rules (~$0.025/час за правило = ~$18/мес), а не за количество балансеров. Если у вас 20 сервисов на одном LB - вы платите за один IP (~$7/мес) + 20 правил (~$360/мес) = ~$367/мес.

Нюанс: реализация завязана на специфику GCP (NEG, backend targets). Без Terraform-модуля управлять вручную - дорого по времени. Зато когда настроено — работает как часы.

Реальный пример:
- Было: 20 сервисов = 20 IP + 20 LB = ~$500-600/мес
- Стало: 1 IP + 20 routing rules = ~$367/мес

Экономия заметна, особенно если сервисов много. Если у вас 2-3 сервиса - возможно, не стоит заморачиваться. Если 20+ - точно стоит посчитать.

---

А у вас как организован Load Balancing? Сколько сервисов, сколько IP? Может, пора пересмотреть архитектуру?
Пишите - разберем ваш случай.

Альтернатива GCP ALB: Nginx-Ingress в кластере

В прошлом посте рассказывал, как использовать один Application Load Balancer вместо десятка отдельных. Но есть ещё вариант, о котором не упомянул - Nginx-Ingress + Cert-Manager внутри GKE.

Как это работает?

Поднимаете в кластере Nginx-Ingress контроллер с Cert-Manager и один Network Load Balancer перед ним. Все сервисы направляются через Nginx, который управляет роутингом и автоматически получает SSL-сертификаты через Let's Encrypt.

Во что обойдётся?

- Network LB: ~$25/мес (IP + forwarding rule)
- Compute внутри GKE: ~$15-30/мес (Nginx-Ingress требует ~0.5-1 vCPU + 512MB-1GB RAM)
- Cert-Manager: практически бесплатно
- Время DevOps: ~4-6 часов на настройку + 1-2 часа/мес на поддержку = ~$50-200/мес (зависит от ставки)

Итого: ~$90-255/мес для 20 сервисов

Против managed ALB (~$367/мес) это дешевле. Главный плюс - универсальность. Не привязан к конкретному облаку, легко мигрировать в другой Kubernetes. Минус — нужна экспертиза в настройке ingress-контроллеров и интеграции в существующий workflow.

Что выбрать?

Managed ALB - если хотите managed-решение без головной боли. Nginx - если есть DevOps-команда и планируете мультиоблачность.

---

Какой подход используете вы? Managed-решения или self-hosted? Пишите

Я каждый день нахожу что-то новое. Или разновидность старого косяка

Сейчас я DevOps/Cloud архитектор, и когда делюсь опытом, одна из первых тем - "никогда не используйте :latest в production". Эта история рассказывает мой случай "почему".

Немного контекста

Работали мы в Azure Kubernetes, команда логгинг/мониторинг. Собирали кастомный OpenSearch, пайплайн билдил образ, вешал версию и переставлял тэг :latest.

После каждого билда мы руками меняли версию в Helm чарте для деплоя. И вот сидим с коллегой, смотрим на очередной перезапуск StatefulSet и думаем:
"А зачем? Давай просто :latest используем? Мы же все равно сразу деплоим?"

Поменяли. PullPolicy был Always, вроде норм.

В чем косяк

Хватило на два деплоя в dev. Потом вылезли нюансы:
- Откатить версию просто так нельзя
- Протестировать образ отдельно перед деплоем нельзя - он сразу катится
- И главное: dev для разработчиков был dev, а для нас - вполне себе прод. Логи-то им все равно нужны)))

Быстро пофиксили, вернули версии. Рабочий момент.

Свежий пример

Месяц назад помогал команде с падением MongoDB в dev:

image: mongo  # без тэга, а значит используется latest

Ноду убрали на maintenance, под переехал и образ перекачался. А 16 дней назад вышла Mongo v8, тэг :latest переехал на нее. Под поднялся с новой версией, а в storage лежала база от старой - несовместимая. Dev не работал несколько часов.

Разработчики были удивлены - они ж в docker compose работают локально, так что для них это просто "хм, интересно, не знали что так бывает".

---

С тех пор (первого случая) я всегда использую явные версии в манифестах. :latest только в локальной разработке, и то не всегда.

Когда хочу подушнить, или объясняю нюансы, то упоминаю что: тэг :latest - это не "последняя стабильная", это "что там сейчас под этим тэгом лежит". Погуглите ":latest problems" - тонны историй "10 способов выстрелить себе в ногу".

Расскажете свою историю с :latest?

Почему ArgoCD, а не просто kubectl apply из Jenkins

Ваш CI/CD врёт вам.

"Deployment successful" не значит что в продакшене работает то, что вы задеплоили.

Увидел пост про ArgoCD. Автор объяснял с точки зрения безопасности - не надо раздавать kubeconfig, все через Git.

Правильно. Но я хочу обратить внимание на то, что ломается в три часа ночи.

Вопрос который задают: "Зачем ArgoCD? У нас Jenkins (Github Actions, GitlabCI, CircleCI, etc.) деплоит, работает же?"

Работает. А потом ты просыпаешься в три часа ночи и фиксишь срочно.

Представьте:

Push-based - это как работать над курсовой.
"Вот тебе курсовая_работа_v3_final_fix_last_checked.doc".
Правишь, проверяешь, правишь, но хочешь сохранить старый вариант, делаешь копию с другим именем. Потом решаешь что нужно иначе, берешь старую, создаешу другую новую. Потом снова правки. Через неделю у вас 5 версий файла, никто не помнит какая последняя, и в итоге сдаёте не ту.

Pull-based - это Google Doc с версионированием. Один файл, вся история сохранена. Внес правки - открыл историю, посмотрел что было раньше, откатился если нужно. Всегда понятно что актуально.

В чём реальная разница:

Jenkins задеплоил. kubectl apply отработал с exit code 0. Билд зелёный. Красота.

Но:
- Кто-то руками поправил deployment в кластере? Jenkins не узнает.
- HPA изменил количество реплик? Jenkins не видит.
- Другой пайплайн перезаписал конфиг? Jenkins пофиг.
- Манифест в Git устарел? Jenkins применил что есть.

kubectl apply - fire and forget. Выстрелил и забыл.

ArgoCD живёт в кластере. Каждые 3 минуты сверяет: "То что в Git = то что в кластере?"
Нет? Фиксит.

Но главное не это.

Главное - кто контролирует ваш production?

Jenkins, GitHub Actions, GitLab CI - это внешние инструменты. Управляются кем-то еще. Их правила, их цены, их breaking changes.

Помните Google URL Shortener? Bitnami образы MongoDB? GitHub Actions меняли расценки?

Когда CI/CD интегрирован в ваш workflow напрямую - вы зависите от него как от критической инфраструктуры. Но не контролируете.

ArgoCD - это часть вашего кластера. Под вашим контролем. Как библиотека в коде, а не внешний сервис.

Мой опыт:

Я видел и использовал оба подхода в production.

Push-based ломается тихо. Всё зелёное, а продакшн лежит. Потому что то что задеплоили != то что реально работает.

Pull-based ломается громко, сразу. Drift detection показывает расхождение. Git log - полный аудит. Rollback = git revert.

Да, ArgoCD - это ещё один компонент. Порог вхождения, настройка, поддержка.

Но для Kubernetes в production - это может критически повысить надежность.

Не всегда, иногда это оверкилл, или ваше приложение не настолько зависит от git - тогда push-based норм.

---

А что обычно у вас ломает деплой ночью - ручные правки, конфликты пайплайнов или что-то другое?

Написал большую статью про то, как я нахожу деньги в облаках 😄

Два реальных аудита, $50k сэкономленных долларов.

Обычная история: компания платит, все работает, никто не жалуется. А потом смотришь — 26 забытых IP-адресов, 300 неактивных пользователей с паролями десятилетней давности, серверы на 15% загрузке.

В статье — как это находить, как считать окупаемость аудита, и чеклист что проверять самостоятельно.

Если интересно — вот ссылка:
[Medium]

Буду рад обратной связи 🙂

В 2018-м Google закрыл goo.gl. Я не потерял ни одной ссылки — просто не использовал его.

Помню, как в 2009-м коллеги говорили: "Зачем свой сервис? Google сделал бесплатный shortener — надёжно, быстро, навсегда".

Логика казалась железной. Google - не какой-то стартап на коленке. Инфраструктура мирового уровня, команда инженеров, репутация. Зачем тратить время на свой велосипед?

В апреле 2018-го сервис закрыли. Не потому что Google злые - просто бизнес-решение. Поддержка стоит денег, монетизации нет, приоритеты сменились.

Что я наблюдал после:

Компании судорожно искали ссылки в документации, маркетинговых материалах, email-рассылках за годы. QR-коды на печатной продукции стали вести в пустоту. Часть просто смирилась с битыми ссылками.

Самое забавное - большинство мигрировало на Bitly. То есть на другой бесплатный публичный сервис.

Это повторяется постоянно:

Parse от Facebook, Google Reader, Docker Hub rate limits, Heroku free tier, некоторые Bitnami образы. Список можно продолжать.

Бесплатный сервис живёт ровно до тех пор, пока компании выгодно его держать. Это не цинизм - это бизнес.

Где граница?

Для MVP, для proof of concept, для быстрого старта - бесплатные сервисы идеальны. Тестируете идею 3 месяца? Отлично, используйте что угодно.

Но если ссылки в клиентской документации, если от этого зависит работа поддержки, если восстановление займёт недели - нужен контроль.

Не обязательно всё поднимать самому. Можно платный тариф того же Bitly с SLA. Можно свой домен на их инфраструктуре. Главное - понимать, что произойдёт, когда сервис закроется.

После 15 лет в инфраструктуре я знаю:

Бесплатное - для экспериментов.

Критическое - под контролем.

Между ними - осознанный риск.

Вы наверняка это знаете. Но, возможно, где-то в вашей инфраструктуре до сих пор есть зависимость, которая завтра может исчезнуть.

Думайте своей головой. Даже если это я говорю.

---

А какие примеры можете привести вы?

Утро пятницы. Кофе. Деплою рутинный апдейт.

kubectl get pods

ImagePullBackOff.

Что…

---

Bitnami переехали с образами MongoDB за ночь.

Старое место: docker.io/bitnami/mongodb
Новое место: docker.io/bitnamilegacy/mongodb

Мой Helm chart: "Эй, Bitnami, где монга?"
Bitnami: "Переехали. Смотри в другом репо."
Мой chart: "Мне никто не сказал."

Ноль предупреждений. Ноль редиректов. Просто исчезли.

---

Самое прекрасное?

Случилось у ТЫСЯЧ команд одновременно.
Кто-то обнаружил при рутинном перезапуске.
Другие — во время настоящего аутеджа.

GitHub затопило воплями "ПОЧЕМУ ВСЁ СЛОМАЛОСЬ"

Ответ Bitnami: "А, да, мы анонсировали. Разве не видели?"

(Они не видели.)

---

Повторюсь:

Бесплатные сервисы меняют правила.
Вы не можете засудить Docker Hub.
Вы не можете требовать SLA по аптайму.
Вы просто... адаптируетесь.

Разумный ход: Зеркалить критичные образы в СВОЙ реджистри.
Ваш AWS ECR. Ваш GCP Artifact Registry. ВАШ контроль.

Стоит $5/месяц. Спасает ваши выходные.

---

Доверять обещаниям вендоров? Конечно.
Но когда их нарушение стоит денег ВАМ, а им ничего...

Может, держать запасной план?

Было у вас "блин, а куда делся образ?" ?

P.S. На прошлой неделе писал про goo.gl - та же история

Я заметил проблем на $17,000 в год.

Клиент: "А можно без аудита? Вы же уже знаете что не так."

---

Поддерживал их инфраструктуру, заметил очевидные проблемы:

- Старый тариф (в 2 раза дороже текущего)
- Забытая тестовая нода, работает впустую
- Загрузка 30-40%, платят за 100%
- Нет автоскейлинга

Потенциальная экономия: ~$1,400/месяц

---

Предложил полноценный аудит:
40 часов - глубокий анализ, план миграции
8 часов - безопасное внедрение

Ответ: "Вы и так знаете что не так. Просто сделайте."

Перевод: "Пропустите аудит. Работайте за 1/5 цены."

---

Что они упустили:

Заметить проблему = 20 лет опыта
Починить безопасно = детальный анализ

Старая инженерная шутка:
$1 - ударить молотком
$9,999 - знать куда ударить

"Вы увидели за 5 минут" = да, потому что 20 лет учился куда смотреть.

---

Почему нужен аудит:

Какие нагрузки можно перенести без риска?
Правильный размер под реальное использование
Последовательность миграции без даунтайма
План отката когда что-то сломается

"Просто сделайте" = рулетка с продакшеном.

---

Отказались. До сих пор платят лишние $1,400/месяц.

Опыт выглядит легко.
Поэтому люди думают что он бесплатный.

Но знания - это и есть работа.