матрица эйзенхауэра, рис, 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 - и я повторяю её в подходящие моменты чтобы произвести впечатление.