Андрей Селькин | Outbox

подписчика

Канал Селькина Андрея – TGM / Go-разработчика из Fintech. Делюсь опытом решения сложных архитектурных задач, управления командой и работы с высоконагруженными финансовыми системами. Технические разборы, управленческие кейсы и личные истории из жизни.

Лента материалов Статьи

1 день назад

• Вы подписаны

Твой список задач требует отдельного тимлида

Открываешь задачи на день. Посмотреть PR, подготовить 1:1, разобраться с таймаутами, согласовать архитектуру. Ещё в чате просят «быстро глянуть». Расставляешь приоритеты. Потом переставляешь. Потом приходит новая задача, и всё приходится пересматривать. До работы пока не дошёл. Планировал работу. ——— Для таких случаев обычно советуют ABCDE или матрицу Эйзенхауэра. В ABCDE задачи распределяют по последствиям: обязательно сделать, желательно, можно обойтись. Что-то делегировать, что-то вычеркнуть. Среди самых важных ещё нужно определить порядок: A1, A2, A3...

3 дня назад

• Вы подписаны

Kubernetes может тормозить приложение на свободной ноде

Выглядит нелогично: процессор свободен, а приложение стоит. Но для контейнера этого CPU уже нет — он исчерпал заданный ему лимит. Чтобы понять, как мы до этого дошли, нужно разделить две настройки: requests и limits. Они стоят рядом в YAML, поэтому их легко принять за нижнюю и верхнюю границы потребления. Но задачи у них разные. По requests Kubernetes решает, на какую ноду поставить Pod. Причём смотрит не на текущее потребление, а на уже заявленные requests. Нода может простаивать, но если Kubernetes уже пообещал все её ресурсы другим Pod, новый Pod на ней не запустится...

1 неделя назад

• Вы подписаны

База от вайбкодера: пока всё работает — можно не разбираться

Сейчас можно открыть Cursor, Claude Code или ChatGPT, написать: Сделай мне сервис. И через несколько минут получить сайт-визитку код. Красота.

1 неделя назад

• Вы подписаны

Безынициативный инициатор

Знания перестают приносить пользу, если они становятся способом отложить решение. О чем это я? Вот есть такой абстрактный коллега, который прочитал много статей, книг, очень круто знает паттерны проектирования и рассказывает тебе про возможные подходы и улучшения. Он всегда предлагает что-то изменить. Новую технологию. Новый процесс. Новый подход. Но есть одна проблема. За последний год он не внедрил вообще ничего. Вечный исследователь: "А ещё такой подход есть. А вот есть такая библиотека. А вот тут можно оптимизировать по ram или cpu. А тут процесс выстроить..." А сделать то пробовал? Ну, прям...

1 неделя назад

• Вы подписаны

«Мы разбираемся» — это не статус!

В предыдущем посте рассказал о том, что такое инцидент, и кто такой координатор. Теперь поговорим о том, как правильно сообщать статус. Прод лежит уже N минут. Бизнес спрашивает: — Что происходит? — Когда почините? — Что сейчас делаете? Ответ: «Мы разбираемся». И что теперь делать бизнесу с этой информацией? Ничего. Во время серьезного инцидента статус нужен не для того, чтобы показать, что команда не сидит без дела. Он нужен, чтобы люди понимали, что происходит и чего ждать дальше. Что написать в статусе? 1. Что произошло? Коротко и без технического шаманства. — Не: «Наблюдаем деградацию одного из downstream-сервисов»...

1 неделя назад

• Вы подписаны

Прод лежит. Кто теперь главный?

Прод упал. Один человек откатывает релиз. Второй лезет в базу. Третий смотрит графики. Четвертый уже пишет бизнесу. Пятый предлагает проверить еще одну гипотезу. Проходит десять минут. У нас семь гипотез, десять параллельных действий и никто толком не понимает, кто всем этим управляет. Это не incident management. Это коллективная паника. ——— Зачем нужен координатор? На серьезном инциденте нужен человек, который в какой-то момент говорит: «Стоп. Делаем вот это». Это координатор. Он не обязан быть самым сильным разработчиком в комнате. Его задача — не чинить прод своими руками. Его задача — сделать так, чтобы прод починили...

Покупайте СтеллыИ дарите их за контент