Прохожу Школу СТО Стратоплана. Часть №2.1. Делегирование.

Обещанный пост с новой порцией конспектов с курса.
———

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

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

———

Как реализовывать делегирование? - через процессы (четкие инструкции, четкие критерии результата, возможность контроля, принятие важных решений в наших руках)

Для того чтобы правильно это выстроить полезен подход RACI, его цель — разграничить ответственности участников процесса через четыре ключевые роли:
- кто выполняет (Responsible) — один или несколько сотрудников, которые занимаются непосредственно работой;
- кто утверждает (Accountable) — ответственный за итог, может не только принимать работу, но и исполнять её вместе с R;
- кто консультирует (Consulted) — советчик по процессам;
- кто информирован (Informed) — заинтересованные лица, которые хотят получать информацию по проекту.

Если приводить примеры инструментов руководителя для реализации делегирования то это в основном 4 штуки:
- Правила и инструкции
- Наличие в процессе обязательного финального аппрува от нас.
- Любые необходимые для реализации процесса метрики и KPI.

———

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

"Делегирование через бюджет" — это управленческий подход, при котором руководитель не просто поручает задачи, но и передаёт подчинённому (или команде) ответственность за принятие решений в рамках определённого бюджета. Это своего рода делегирование полномочий с финансовыми рамками.

———

Метрики - основной инструмент руководителя. Без них просто невозможно отслеживать изменения и руководить командами отделами и департаментами. Их довольно много и зависят от того какие конкретно инструменты в компании используются (например Kanban или Scrum). Верхнеуровнено важно отслеживать метрики по PMBOK (про бюджеты, сроки, стоимость).

Хороший пример фреймворка который отслеживает удовлетворенность пользователей - HEART Framework

Дополнительные ссылки:
- Kanban Metrics
- Scrum Metrics
- Метрики продукта

Решил сделать перерыв от высоких менеджерских материй и попостить простой годноты, которую встречаю в day by day работе.

Сегодняшний лот - статья с подробнейшим разбором такого понятия как CPU Throttling.

Под катом:
- Что такое CPU Throttling, какое влияние оказывает на сервис под нагрузкой?
- Как в K8s работают CPU limits?
- Как можно столкнуться с CPU Throttling на примере Golang?
- K8s limits, requests + GOMAXPROCS
- Milliseconds vs Cores, что будет если установить программе в K8s лимиты < 1?

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


https://kanishk.io/posts/cpu-throttling-in-containerized-go-apps/

-----

Делитесь в комментариях своим опытом связанным с CPU нагрузками, где и чего оптимизировали, как избавлялись от троттлинга сервисов?😊

Prometheus: How We Slashed Memory Usage

https://devoriales.com/post/384/prometheus-how-we-slashed-memory-usage

#prometheus #monitoring #observability

​Prometheus Monitoring: Functions, Subqueries, Operators, and Modifiers

Статья из блога VictoriaMetrics о функциях, подзапросах, операторах и модификаторах.

⚡️ Composerize — мгновенное преобразование docker run в docker-compose. Composerize решает проблему нечитаемых строк с десятками флагов одним движением — конвертирует запуск контейнера через CLI в аккуратный compose.yaml.

Инструмент доступен как, так и npm-пакет. Под капотом — парсинг флагов с их корректным переносом в YAML-структуру. Проект особенно удобен, когда нужно интегрировать новый сервис в существующий стек: Composerize умеет мержить конфиги, поддерживает разные версии Compose и даже настраивает отступы.

🤖 GitHub

@DevopsDocker

Исследование состояния DevOps в России 2025

Дорогие друзья, мы рады сообщить, что «Экспресс 42» при поддержке генеральных партнеров запустила ежегодное исследование состояния DevOps 2025! Мы планируем опросить больше 4000 представителей индустрии, связанных с DevOps: инженеров, разработчиков, администраторов, тестировщиков, техлидов и тимлидов, CIO и CTO.

Если тема DevOps вам не безразлична — пройдите опрос и внесите свой вклад в развитие индустрии. Важно мнение каждого респондента!

📊 Ключевой темой исследования в 2025 году становится Developer Experience (DX) — то, насколько опыт разработчиков влияет на эффективность команд и успех компании.

🎁 По завершении опроса вы сможете поучаствовать в лотерее с розыгрышем классных призов от организатора исследования и генеральных партнёров.

Заполнить анкету 👉 по ссылке

#машины_разное

Рассказал на Tech Internals Conf, он же англоязычная вариация Highload++, про миграции API.

Рекомендуется к просмотру аудитории любой степени подготовки.

​The Lost Fourth Pillar of Observability - Config Data Monitoring

Уже много было написано о журналах, метриках и трассировках, они действительно являются ключевыми компонентами в наблюдаемости, мониторинге приложений и систем. Однако, часто упускают из виду данные конфигурации и их наблюдаемость. В этой статье рассмотрено, что такое данные конфигурации, чем они отличаются от журналов, метрик и трассировок, и обсуждается, какая архитектура необходима для хранения этого типа данных и в каких сценариях она представляет ценность. Читать дальше.

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

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

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

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

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

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

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

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

Тут в дело вступает, на мой взгляд, первая ошибка (а не просто человеческая небрежность) инженеров — система контроля доступа настроена так, что при отсутствии ответа от программы проверок она отклоняет запрос. Так называемый fail closed. Хорошо для замков на банковских сейфах, плохо для пожарных выходов.
В нашем случае система не пропускает ни один запрос.

Дежурные инженеры замечают проблему в течение 2 минут, за 10 минут находят причину (дежурная система и дежурные инженеры у Гугла достойны восхищения) и нажимают большую красную кнопку, которая должна выключить эту часть программы (ее программисты сделали). Ее включение занимает еще 30 минут. (Не понятно, почему этот механизм занимает 30 минут, а не 20 миллисекунд, но движемся дальше).

Система заработала, но из-за того, что она лежала 40 минут, накопилось много желающих отправить запрос еще раз, и они создали эффект толпы, которая набежала и перегрузила остальные соседние сервисы через наш сервис проверок. Оказалось, что он не ждет какое-то время, если нужный сервис отказывается ответить на запрос (для этого есть красивая схема exponential back off), а долбит до упаду, тем самым не давая системе возможности восстановиться. Пришлось руками ограничивать число запросов. На постепенную, ручную разгрузку очередей ушло еще 2 часа.

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

Как вывод, Гугл обещает пройтись по всем сервисам и убедиться, что они, во-первых, fail open, то есть пропускают запросы, когда падают, во-вторых, реализуют exponential back off, если на их запрос не отвечают, а не добивают лежачего, и, наконец, в-третьих, что даже глобальные добавления правил должны прилетать во все регионы не сразу, а с некоторыми задержками. Ещё обещают добавить эти проверки в свои статические анализаторы кода, завидую!

Первые два пункта можно и нужно использовать в каждом проекте, даже если ты не Гугл.

Terraforming Your Grafana Alerts for Kubernetes Clusters

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

❗️Статья на medium.com

Прикрутим персистентность - I

Давайте сделаем упражнение в "системном дизайне". Предположим, мы написали простенькое in-memory хранилище, но нас не устраивает, что данные теряются при рестартах, надо прикрутить "сбоку" персистентность. Строгая консистентность вам не очень нужна, но желательна. Как добавить эту персистентность?

Можно делать снепшотирование: fork(), запись на диск. Можно писать лог обновлений на диск (сразу, или нет - в зависимости от требуемых гарантий). Можно использовать комбинированные методы. Давайте обсудим, мне кажется, хорошее упражнение на понимание архитектурной “внутрянки”.

Допустим мы снепшотируемся через fork(). Что происходит сразу же: copy-on-write. Это такая оптимизационная стратегия управления памятью, при которой копирование объекта откладывается до тех пор, пока одна из сторон не попытается его изменить. Если данные не меняются, читаем одно и то же из “пошеренной” страницы. При изменении создаётся копия. Поэтому после fork() ядро дублирует страницу только в тот момент, когда соотвествующий участок памяти обновляется в родительском процессе нашего kv—хранилища: мы же продолжаем принимать апдейты от клиентов.

Если наше kv-хранилище получает апдейтов много, то в самом плохом случае нам может понадобится в два раза больше памяти: ядро при каждом обновлении страницы начнёт создавать копию, а максимальное количество копий даст удвоение по памяти. Именно поэтому для Redis рекомендуется держать свободными десятки (!) процентов памяти, иначе может быть больно - и это абсолютно смешное требования с точки зрения любой “нормальной” СУБД. Буквально несколько недель назад я вот так угандошил кластер Redis на демо, и даже сходу не разобрался почему 🙂

Несмотря на такую прожорливость по памяти, метод снэпшотирования через fork() удобен. Во-первых, он очень простой и программируется левой ногой. Во-вторых, мы получаем консистентный (насколько это возможно в отсутствие транзакций) снэпшот: ведь любой изменение после старта снэпшотирования меняет копию, а не снэпшотируемую страницу. До сих пор Redis снэпшотировались именно так (чуть сложнее, но полный снэпшот всё равно делается, и это происходит через fork()).

Про остальные методы прикручивания персистентности напишу позже.

——
Учись, пока AI тебя не заменил: Производительность и наблюдаемость бэкенда (3 июня), Redis и Valkey: от основ к хайлоаду (9 июня)

Полезная таблица инструментов DevSecOps

Если ты учишься с нуля, устраняешь пробелы или заменяешь существующие инструменты, начни с Периодической таблицы, чтобы подобрать оптимальные решения для своей DevOps-пайплайна.

#devops #девопс

@devopsitsec

#машины_разное

Я думаю, все и так достаточно рассосали падение Гугла, поэтому давайте расскажу в нескольких постах подробнее про feature flag’и, и какие у них есть полезности.

Из очевидного - безопасность сервиса. Представьте себе мечту Андрея Синицы DevOps и SRE любителей, где в секунду выкатываются десятки изменений.

Если в релизный цикл попадет баг, и нужно будет откатиться, то вы откатите не только свое изменение, но и другие (а там могли быть критические фиксы!), и будете делать это долго: плохие экземпляры потуши, старые релизные подними, трафик перенаправь, а если это делается глобально, то и сам релиз откатываться начнет не сразу (смотря как быстро алерт сработает), да и возвращаться будет долго.

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

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

Более того, выкатку флага тоже можно и нужно контролировать с таким же усердием, как и сам релиз. Например, повесить на флаг те же алерты, что и на сервис, включить флаг для 1% запросов в canary, и смотреть как та пищит. Если у нас выстрелил алерт по SLO доступности, то дело скорее всего в фиче, и система выкатки так же умно его откатит назад.

Инженеру остается проанализировать логи, написать фикс и повторить итерацию.

Позже расскажу про как флаги позволяют контролировать выполнение кода, но пока поспекулирую, что флаги пропускают либо когда очень спешат (а в нынешней экономике все очень спешат), либо когда риск изменения низкий. А ваш покорный прилично инцидентов просмотрел, триггерами которых являлись «низкорисковые» изменения. :)

#машины_разное

Само понятие «флаг» может произвести впечатление, что это какой-то тумблер «вкл/выкл», который захотел включил, захотел выключил.

Самый простой флажок будет выглядеть именно так, но ✨настоящая магия ✨ прячется за условиями выполнения, которые могут быть статическими и динамическими! Давайте на примере расскажу про Configuration Driven Development (далее CDD).

Итак, у нас есть флаг и есть часть кода, где мы спрашиваем значение флага. Флаг всегда возвращает «да» или «нет» или строку с числом, но логика внутри флага может быть умнее.

Самый простой флаг, который определяет какой адрес базы дать на базе энва будет таким псевдокодом на YAML:

default: prod-db
flags:
- test:
if:
- env = testing
then: test-db
- prod:
if:
- env = production
then: prod-db

Опытный инженер увидит подозрительное default, которое может нагнать страх, и этот страх вполне оправдан. Выбирая между «передаем по умолчанию прод, и возможно не тот енв получит доступ» и «передаем null, и приложение упадет», я бы выбрал второ- исходя из ситуации.

А что если нам нужно обслуживать тестовый трафик в промышленной среде? Тогда можно опираться на заголовки запроса и обогатить нашу логику.

default: prod-db
flags:
- test:
if-one-of:
- env = testing
- req-tenancy = test
then: test-db
- prod:
if-one-of:
- env = production
- req-tenancy = prod
then: prod-db

А что, если нам нужно обеспечить теневой трафик, который живет в рамках теста, но нуждается в "живых" данных? Тогда можно использовать использовать логическое умножение:

default: prod-db
flags:
- shadow:
if-all-of:
- env = testing
- req-tenancy = shadow
then: prod-db

Тут вы наверняка скажите: «Карен, ты упоролся, connection string к базе инициализируется на старте приложения, а ты предлагаешь это делать на каждый запрос?!», а я вам отвечу: «Не душните, взял самый наглядный пример, чтоб всем было понятно!»

У CDD очевидно есть и бизнес применение, например решать в какой PSP передать платеж на базе параметров платежного поручения. Представьте себе такое:

flags:
- dest1:
if-all-of:
- country-code = BR
- payment-method = payment_card
- card-type = debit
then: psp1

Количество таких параметров ограничивается вашей фантазией, а вы на базе десятков таких конфигураций сделали самый что ни на есть платежный маршрутизатор! Причем новые маршруты можно добавлять не трогая приложение вообще.

Я не зря оговорился о разношерстных параметрах, ведь диверсификация параметров это необходимая составляющая экспериментов!

У вас бывало такое, что вы запускаете любое мобильное приложение, а оно ПОЧЕМУ-ТО ведет себя иначе? А потом точно так же ПОЧЕМУ-ТО ведет себя как раньше?

Это означает, что вы попали под эксперимент. Эксперименты это целые наборы флагов, которые принимают в качестве параметров… да вообще что угодно, от страны и устройства до пола, возраста, и последних 10 пролайканных фоток. Эксперименты проверяют жизнеспособность фич и их полезность, поэтому ставятся на длительный период и измеряют бизнес метрики навроде конверсии. Если цифры идут вверх, расширяем поле экспериментов дальше, пока не уйдем на 100%.

Платформа экспериментации - красивая обертка над системой конфигураций, feature flag’ов, мониторинга и механизмов раскатки, и стоит на вооружении у всех больших дядечек и тетечек.

В следующем посте постараюсь собрать для вас подходящие инструменты, с которыми вы можете использовать feature flag’и с минимальным ущербом для здоровья.

Подборка, в которой мы хотим поделиться новыми тулами из мира Kubernetes. Тут Portainer запустила дистрибутив для 200 МБ RAM, k0s попал в CNCF Sandbox, а новые инструменты упрощают управление мультикластерными средами. Смотрите сами.

Портативный Kubernetes для минимальных ресурсов
Portainer представила KubeSolo — ультралегковесный дистрибутив Kubernetes, который работает всего с 200 МБ RAM. Без кластеризации и etcd, идеально подходит для ограниченных сред.

Мультикластерное управление
kubectl-foreach позволяет выполнять kubectl-команды параллельно в нескольких кластерах одновременно.

k0s присоединился к CNCF Sandbox
Легковесный дистрибутив Kubernetes от Mirantis получил официальное признание в CNCF. k0s выделяется единым бинарным файлом со всеми компонентами Kubernetes, а ещё он подходит для edge-вычислений и ресурсоограниченных сред.

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

Как работает DNS в Linux. Часть 1: от getaddrinfo до resolv.conf

Когда мы вводим в браузере имя сервера или доменное имя сайта, выполняем ping или запускаем любое удаленное приложение, операционная система должна преобразовать указанные имена в IP-адреса. Этот процесс называется разрешением доменного имени. На первый взгляд он может показаться весьма прозрачным, однако за ним скрывается многослойный механизм.

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