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

Я удалил сайт с хранилищем и базой на 110 гигабайт. Это не особо много, но это вся история бизнеса за 5 лет.
Вы можете сказать - "плохо что даунтайм, наверное целый день/ночь восстанавливал?"
Нет.
Я удалил его полностью, без возможности восстановления.
Потому что там не было никаких бэкапов. Никаких. Ни настроек, ни контента. Ничего.
Сайт буквально жил на носу несущейся ракеты, и я просто был тем самым камешком что сбил его просто коснувшись.

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

Итак, что вы чувствуете? Представьте эту ситуацию:
Ваш успешный сайт/сервис/приложение работало-работало, а потом бац! и ваш сотрудник случайно его удаляет.
Давайте, не стесняйтесь, прочувствуйте это.
5 лет SEO. Позиции в Google которые копились годами - это не восстанавливается за день, это месяцы работы поисковика.
Контент написанный вручную. Аккаунты пользователей. История заказов, обращений, всего что там было.
Все что нажито непосильным трудом, длинными ежедневными часами разработки, написания, редактирования, все пропало.
Совсем пропало. Абсолютно. Исчезло.


ЗЫ:

Здесь должна быть история как мы успешно все восстановили, LessonLearned и прочий буллшит.
Но ее не будет.
Потому что здесь нечего восстанавливать. Да, картинки наверное остались. Может быть осталось что-то еще. Где-то.
Но это не восстановление из бэкапа, даже супердолгое.
Это пересоздание, кем-то как-то... Это может стоить вам бизнеса.

матрица эйзенхауэра, рис, wtf и другие матерные слова в работе инженера

"Как вы расставляете приоритеты между задачами - например, вот фронтендеры хотят срочно сейчас, и бэкендеры тоже хотят срочно сейчас, но другое?"
Я вот задумался...
Как-то не возникало раньше настолько конфликтующих задач, когда час времени влияет. Обычно хватало "сегодня сделаю", и так получалось что что-то я делал в первую очередь (попроще, понятнее, просто быстрее), а что-то во вторую, но в рамках одного дня это не существенно. Если же задача больше чем на один день - то тем более не критично.

-—
В командах с тимлидом это его головная боль. Но работая соло с несколькими командами одновременно - приходилось развивать и навыки планирования.
В-основном это выглядит как интуиция - "это быстро, сделаю", "тут надо копаться, но команде не горит, отложу и спокойно изучу", "это срочно, бросаю все и жечь напалмом".
На самом деле - тут все логично, и даже есть умные слова для определения методик.
Я их не знал, мне хватало нормального описания в книге "Тайм-менеджмент для системного администратора" Томаса Лимончелли, чем, собственно, и руководствовался все 16+ лет.

Но согласитесь, это не тот идеальный ответ, который предполагается в разговоре, где надо показать отглаженный воротничок.
Пошел изучать.

Матрица Эйзенхауэра - это тот крестик с половинами "срочно/не срочно" и "сложно/не сложно", или как-то так. Это первичный фильтр. Прод горит? Чини сейчас. Остальное - сортировка.
RICE - для планирования. (Reach × Impact × Confidence) / Effort. Дает число. Ну а потом сортируешь по величине, да и все.
WSJF - для выбора "что делать прямо сейчас". Учитывает стоимость задержки - что мы теряем каждый день пока не решили. CI/CD падает каждый третий деплой? Каждый день теряются часы инженеров. QA ждет окружение? Пока не ждет - у него есть другие задачи. Отрубился автомат в распредщитке в офисе - оооо, почти все сотрудники бездельничают, а часы капают.

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

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

Вы дали ИИ больше прав чем новичку в его первый день?
И чему вы удивляетесь?

Я использую ИИ (claude code), реально полезная штука. Планирую, обсуждаю архитектуру, прошу написать код, проверяю.
И никогда не позволяю "сделай что-нибудь, вот тебе права на всё".

Я собирался засечь сколько времени мне понадобится чтобы задеплоить кластер k8s с нуля в Hetzner.
ИИ сделал мне план, обсудили шаги, сгенерировал последовательный howto. Прекрасно.
Конечно, я не перепроверял каждую команду в плане. Я нормальный.

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

Косяки были не только из-за ИИ. Конечно, всякие несуществующие параметры были. Но также повлияло несовершенство hcloud утилиты.
Например, маршруты балансировщика нагрузки: при пропущенном параметре консольная утилита создала без ошибок, успешно. Только оно не работало.

В результате, кубер кластер я создал за два часа, примерно. Делаешь по плану, что-то не так - фиксишь, продолжаешь.
Во второй прогон я поднял его за 40 минут.


Когда я читаю всякие новости "блабла сломалось из-за того что ai получил слишком широкие права; аи обошел запрет и получил права и удалил кластер;"...
Мне дико странно такое видеть.

Vercel взломали в апреле 2026 из-за нажатия "Разрешить все".

Я воспринимаю ИИ-помощников как джунов. Он пишет код, не всегда оптимальный, но очень быстро. Я планирую, правлю архитектуру, с его помощью и вместе мы получаем результат быстрее.
Но пустить его в прод, сказать "эй, сиди здесь, обрабатывай запросы, вот тебе рут-доступ" - вы ебанулись?

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

Вот прямо сейчас возьмите и проверьте как ваши сотрудники могут сломать вашу систему.

K8s 1.26->1.33. 4 часа нажатия кнопки "обновить" в Oracle Cloud.

Там нодпул жесткий, оказывается, а не динамический.То есть, при создании нодпула вручную указываешь AZ где создавать, отдельно для каждой ноды!!!!! и так же руками указываешь сеть.
Вот где я с благодарнростью вспомнил ноды gke, которые автоматически динамически обновляются сами, незаметно.

И вот я руками в веб-консоли нажимаю кнопку "обновить", три раза, с паузами.
Создаю новый нод пул со второй попытки, отключаю старые ноды по одной (даунтайм подов до 14 минут! что у них там с сетью?).
Снова жму "обновить" три раза... Создаю новый нодпул, отключаю старые ноды...
Жму "обновить" два раза и решаю на этом остановиться - ибо уже дофига на это потратил, и слава яйцам версия 1.34 будет актуальна до октября 2026.

Всё началось с диска D.

Помните? Игры на D, документы на D. Диск C - под систему, раз в полгода форматируем.
Один мой коллега пошёл дальше: настроил винду один раз, снял образ, и после форматирования накатывал именно его. Не переустанавливал - восстанавливал.

Прошло двадцать лет. Мы называем это "контейнерами".
Та же идея: данные отдельно, исполняемые файлы отдельно. Только теперь сама ОС стала "исполняемыми файлами". Запустил новый образ - всё работает.

И вот вопрос: зачем тогда делать do-release-upgrade на нодах кубер кластера?

Вывел ноду из ротации. Накатил новый образ. Вернул в кластер.
Это не обновление - это замена. Намного чище.

Не процесс - результат.

Я не смог объяснить что я делаю.
Я пытался простыми словами объяснить чем я занимаюсь как айтишник.

Вот эти все облака, девопс культура, сервера...

Человек взрослый, современный, пользуется телефоном, компьютером, сайтами и приложениями.
Никак.

Это было обескураживающе.

Помогите - как объяснить "пятилетнему" что такое "сервер", и что такое "облако"?
Просто, без зауми и лекций на месяц для определения терминологии.

Помните историю как я грохнул продакшен сайт без возможности восстановления? https://www.linkedin.com/posts/anton-yushkov_devops-backup-incident-activity-7458476375423963136-ri1W

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

Всего-то небольшой конфиг, скрипт для копирования бд и файлов на сетевое хранилище, и настройки для регулярного запуска в кластере.
Меньше одного рабочего дня на создание, еще день на отладку и проверку.

Один день обычной работы против недель на восстановление и неизвестное количество усилий.

У вас есть бэкапы? Точно?

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

Это как с вакансиями - сначала пара больших абзацев про крутую команду и как мы меняем мир, потом key requirements.
Я читаю только requirements.

Короче, клиент: стартап, что-то для школ в США.
У них был рабочий проект, клиенты, нормально всё.
Правильный стартап - сделали чтобы работало, получили клиентов, на заработанное допиливают чтобы работало надёжно.

Что я знаю про проект? Полностью серверлесс - лямбды, S3, Aurora. Cognito, apigw - ну там тоже всё это есть.
Смотришь архитектуру, уточняешь детали, оптимизируешь, пишешь terraform/terragrunt, новый аккаунт, CI/CD, мониторинг. Стандартно.
Сделали, остались на поддержке - под новые фичи допилить, и всё такое.

Чем они занимаются? Честно - не знаю. Я как-то пропустил представление, или не вслушивался, или просто забыл.
Нам абсолютно насрать в чём заключается их уникальная идея. Нас спрашивали про лямбды.

Справились два девопса на полдня за пару месяцев.

Звёздная история? Её нет.
Просто обычная работа.

Есть клиенты у которых деньги есть. Есть клиенты у которых денег нет. И есть третий тип.

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

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

Владельцы же бизнеса "так себе", вроде и не загибается но и успешным успехом не назвать. Наверное, самый некомфортный тип клиентов.
Хотят вот этого всего забесплатно.
Я писал пост о них. Почти год думали, вроде решились.
Неделю им делал, красиво расписал, все подсвечено...
"если со своей стороны подтвердите что вот этот кластер не нужен (а я проверил - на него трафика нет, доменов нет, данных нет), то разом срежем половину ваших затрат. Ну и остальное вот тут, тут и тут - почти половину от оставшейся половины"
"На данный момент этот твой аудит для нас - чистый расход, никакой пользы. Это должно было быть сделано в рамках имеющегося контракта devops support."

Ну блин.

Ты потерял $35,000. Хочешь знать где?

Для тех кто регулярно платит за AWS и не уверен что понимает за что именно.

Ни один клиент не ушёл без находки. На скрине $1000/m только за extended support старых версий БД. И это не самый крупный случай.

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

- Без погружения в биллинг, тарифы и учёт трафика
- Без страха выключить нужное и уронить прод
- Ты рассказываешь - я показываю что и где. Чётко, без жаргона

Посмотри как это выглядит → https://itaudit.yushkov.org/reports/demo/

Вообще, у меня есть аналогичный скрипт для k8s [https://www.linkedin.com/posts/anton-yushkov_aws-finops-cloudcosts-activity-7470511751902580736-XueG] - показывает что сомнительно что можно улучшить.
Слава kubernetes за формализованные правила и рекомендации.
Когда не надо изобретать свой собственный вариант HA, или подстраиваться к конкретной реализации софта - это удобно.

Так вот, про скрипт - лично для меня, того кто этот кластер поддерживает и обслуживает, этот дашборд кажется не очень-то и полезным.
Но вдруг кому-то интересно что можно собрать по-быстрому из k8s кластера и подсветить?

Без долгоиграющих настроек, просто разовый слепок.
https://itaudit.yushkov.org/reports/demo/k8s.html

Мне нравятся метрики.
Но я не люблю алерты.

Весь этот стек - prometheus (или victoriametrics) + grafana + alertmanager + loki, а если нужен нормальное хранение - thanos (storage, compactor, query...). Поднять несложно - а потом ныряешь в ад обслуживания.

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

Сделал свою статус-страницу на обычных метриках: healthcheck подов и вычисляемые правила. Горжусь до сих пор.
Конечно, не конкурент betterstack uptime monitor (бесплатный, кастомный домен, брендинг, несколько проверок).
Но это было моё. Я сделал, оно работало в проде и было надёжным.

Да, метрики люблю - алерты в 3 ночи нет (привет, стандартный тезис от ИИ).
Автоматизация - вот ключ. Ради этого и придумали вычислительные машины.

Зачем ставить алерт, если можно сразу задать действие? Порог, правила, действие.
Автоскейлинг, рестарт, восстановление, банхаммер, принятие решений...

И всё это без ИИ. Если можешь описать правила словами - можешь автоматизировать скриптом в килобайты памяти.


PS: иногда в моменте выгоднее выключить сервис, чем масштабировать до небес)

Знаешь кого-то, кому нужно построить IT инфраструктуру для приложения с нуля?

Сегодня разговаривал с другом - говорили про управление талантами. Неожиданно, да?

Есть создатели и есть те, кто поддерживает. Некоторые компании реально умеют с этим работать: пересаживают людей на подходящие места.
Создатели создают. Поддерживающие поддерживают. И не надо их смешивать.

Я всегда был в поддержке. Это просто: есть документация, есть правила, следуй им, повторяй. Легкий старт - просто обслуживай ПК, сети, серверы, облака.

Создавать новое всегда было для меня сложно.
Не сделать - а решиться попробовать.
Но я всегда немного завидовал тем, кто создаёт. Что-то настоящее.

Идей было полно, проработанных до мелочей.
Самая глубоко проработанная - пятистраничный дизайн рюкзака для художника на пленэре. Из джинсы, вроде мягкого кейса для всех инструментов - кистей, красок, мольберта. (да, я тогда учился в художественной школе)

Ок, считаю что нашел вариант. Инфраструктура.
Надо построить ит-инфраструктуру с нуля для чего-то реального?
Я могу помочь.

Спроектирую и реализую систему под твои бизнес-задачи: масштабируемую, отказоустойчивую, высокодоступную.
GCP, AWS или bare metal Kubernetes. SOC2, PCI-DSS - если нужно.

Я понимаю что это звучит как питч. Это и есть питч. Но предложение реальное.

Что получишь: хорошо спроектированную, экономичную, воспроизводимую инфраструктуру, которая будет расти вместе с бизнесом.

Два варианта:
1. Бесплатно. Абсолютно бесплатно, в мое свободное время. У меня будет достижение, у тебя - инфра.
2. За деньги. Гарантия что работа будет сделана как договорились.

Разницу понимаешь.

PS: знаю, что большинство моих контактов и подписчиков - коллеги: DevOps и инженеры. Много спасибо за репосты и не только.

Что ты выберешь и почему?
Есть два пути и оба правильные.

AWS NACL. Нужно закрыть один порт - и сделать это можно двумя способами:
1. Добавить правило "deny" с более высоким приоритетом, перед правилом "allow".
2. Разбить одно правило "allow" на два, исключив нужный порт из разрешённого диапазона.

У нас есть вот такие причины:
Если мешать "deny" и "allow" правила - внимание рассеивается. Надо держать в голове каждый диапазон: что разрешено, что запрещено, плюс порядок нумерации. Запутаться легко.

Другое дело, если у тебя только одно "deny all" в конце - последнее правило, которое применяется последним. Тогда все остальные правила - только "allow". Проверяешь проще: смотришь только на список портов, не думаешь про тип правила.

Звучит разумно, да? А теперь нюансы.

Пока портов немного - всё хорошо. Но когда их сотни с разными диапазонами - начинается веселье.
Например, блокируем RDP 3389 - вместо одного правила получаем два диапазона.
Все порты ниже 1024 тоже закрыты (кстати, помнишь почему?).
Потом блокируем 3306, 5432, 6379 и так далее.
Уже пять диапазонов. Каждый новый блокируемый порт меняет существующее правило и добавляет ещё одно.

Вот мы и пришли к сравнению двух подходов: "deny all" и "allow all" в конце.
При "deny all" - явно разрешаем нужные порты.
При "allow all" - явно запрещаем ненужные.

Почему не выбрать один подход для всего? Потому что ситуации разные.

В AWS Network Access Control List есть два списка правил - для ingress и для egress.

Для ingress обычно используют "deny all" - безопаснее.
Для egress - "allow all", потому что обычно хочется свободно ходить из своей сети в интернет, верно?

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

И тут приходим к ответам на запросы))))
Когда приложение отправляет запрос куда-то, оно должно получить ответ. А по протоколам TCP/IP ответ приходит на случайный порт где-то в диапазоне 40к. 😉

Но NACL - stateless штука! Он не помнит, что разрешил спросить секунду назад, и не пропустит ответ автоматически "потому что ты только что спросил". Это фича security group.
Для NACL нужно явно описать список портов, которые можно пропустить, в каждую сторону.
Вот почему у нас есть правило allow ingress для диапазона 1024-65535. С исключениями.

Небольшие нюансы Dockerfile

Сначала чуть-чуть базовой информации:
Каждая команда в докерфайле (RUN, COPY, ADD, etc) - это отдельный слой поверх предыдущего.
Слои неимзеняемые. То есть, сли вы во второй команде меняете те же файлы что изменялись в первой - вы получаете новый слой с измененной копией тех файлов.

В частности поэтому можно встретить команды вида

RUN apt update \
  && apt install bla-bla \
  && rm -rf /var/lib/apt/lists/* \
  && apt-get purge --auto-remove -y bla \
  && rm -rf /src/*.deb

Это сделано для того чтобы в одном слое добавить нужные файлы и сразу в нем же удалить ненужные.

Отсюда следует не совсем очевидное.
В наборе команд:

COPY ./ /app
RUN chown -R blabla /app

мы получаем *два* почти одинаковых слоя с файлами /app.
То есть, увеличение размера образа.
Большой размер образа увеличивает время старта приложения, и стоимость его хранения.

Два года назад я поискал решение для получения стоимости нагрузки в кубере.
Нашел kubecost, воткнул.
Ну средней паршивости штука была. Интеграции в платной версии. Дефолтный дашборд непонятный, стоимость взята с потолка.
Лучшее что он умел - написать "вы можете сэкономить $300" без объяснений откуда цифра и что конкретно делать.
Что-то мы оттуда получили.
Год назад ее купил ibm, и даже базовая открытая версия кончилась.

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

Мораль? да пох на нее.

Добавляли вторую S3 репликацию - была в азии для скорости, добавили орегон для бэкапа.

Написали новое правило репликации с filter {} как в примерах. Старое правило оставили без него - зачем? Поле пустое, параметров там никаких.
Сэкономили на строках и буквах.

api error InvalidRequest: Number of distinct destination bucket ARNs cannot exceed 1

Внезапно выяснилось:

S3 replication есть в двух версиях конфига.
V1 - без filter. V2 - с filter, даже пустым. Multiple destinations поддерживаются только в V2.
И если в одном конфиге есть хотя бы один V2 rule - все остальные тоже должны быть V2.

Без filter {} AWS молча считает rule версией V1.

В официальной документации <Filter> есть в примерах и написано что его можно заполнить через <Prefix>. Что его отсутствие определяет версию конфига - не написано.

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

Фикс: добавили filter {} к старому правилу, оба стали V2, multiple destinations заработал.

Я не люблю VITE и вообще реакт-статик сайты.
Это не что-то рациональное, это просто личные ощущения.

Сейчас я понимаю что это просто недостаток моих знаний при первом столкновении. Плюс низкая культура DevOps в компании - разработчик вообще не понимал как работает инфраструктура и кубер. И не мог внятно объяснить почему для этих сайтов важно использовать публичные адреса бэкенда (VITE_API_BASE_URL) во время сборки.

Я в тот момент по-хорошему мог бы задаться вопросом "почему так" и потратить время чтобы разобраться. Но не сделал, не осилил.
Это привело к часам моих попыток донастроить это так, чтобы оно работало по внутренним k8s dns адресам кластера - *.svc.cluster.local
Вот те кто в курсе сейчас, наверное, поржали.
А до меня только на той неделе дошло, и чатик подтвердил с пруфами в чем смысл.

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

"DevOps - это не роль, это культура"

Мой брат всегда вворачивал эту фразу когда упоминался термин DevOps - и я повторяю её в подходящие моменты чтобы произвести впечатление.