Вредные советы: Почему не нужно писать документацию к 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? Может, пора пересмотреть архитектуру?
Пишите - разберем ваш случай.