Я узнал о... #3: DevOps фреймворк DORA

DORA - это DevOps фреймворк из 4-х метрик, которые помогают оценить эффективность и качество релизного процесса.

Фреймворк придумала компания с таким же названием (DevOps Research and Assessment). Скорее всего, чтобы проще продавать свой консалтинг. В 2018-м году эту компанию купил Google Cloud и сделал своей... командой.

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

Собственно, сами метрики:

1) Частота деплоя (deployment frequency)

Показывает, насколько адекватный уровень автоматизированного тестирования. И умеет ли команда релизить точечно, а не сразу всё.

Критерии:

• отлично: несколько раз в день;

• хорошо: раз в 1-7 дней;

• средне: несколько раз в месяц;

• плохо: реже, чем раз в месяц.

2) Время от коммита до деплоя (Lead Time)

Показывает, как долго мы тормозим с бюрократией после момента, когда код уже готов. Низкое значение - неэффективное тестирование, процессы ревью или разработки.

Критерии:

• отлично: меньше дня;

• хорошо: от 1-го до 7 дней;

• средне: 7-30 дней (*по оценке компании DORA, я бы сказал, что это плохой результат);

• плохо: дольше месяца.

3) % сбоев после релиза (Change Failure Rate)

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

Критерии (% релизов, которые привели к сбою):

• отлично: <5%;

• хорошо: <10%;

• средне: <15%;

• плохо: >15%.

4) Скорость восстановления (Mean Time To Recovery)

Показывает, как быстро мы поднимаем прод, если он сломался (упал, пришёл DDOS, выключились сервера). А ещё, умеем ли мы определять и измерять сбои. Упавшим продомом считается или факт того, что существенная часть системы недоступна, или коммит с hotfix'ом.

Критерии (как быстро поднимаем прод):

• отлично: меньше часа;

• хорошо: меньше дня;

• средне: меньше дня;

• плохо: больше дня.

Когда это нужно?

Для себя я выделил три критерия, когда эти метрики имеет смысл считать:

1. Когда есть конкретный продукт в активной стадии развития с постоянной командой хотя бы из 3-5 разработчиков. Т.е. это не что-то, что получает несколько фич в месяц или находится в стадии активного саппорта.

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

3. Когда СТО\CIO нужны хоть какие-то метрики для отчётности. Чтобы объяснить инвесторам или нетехнической части C level'a, что в компании или команде хороший DevOps процесс (или, наоборот, плохой).

DORA метрики измеряются через GitLab или почти любую другую систему CI \ CD. GitLab умеет считать всё это из коробки. За исключением, наверное, падения прода (что тоже можно добавить вручную или вебхуками \ alert manager'ами).

---

Мой Telegram канал про разработку.
Мой open source проект для бекапа PostgreSQL - GitHub.

Я узнал о... #2: Obsidian

Obsidian - это система для ведения заметок с построением графов связей и open source плагинами. Все заметки хранятся локально в .md файлах, но умеют синхронизироваться между устройствами всего за $5.

Много раз слышал о ней от разработчиков и GTD‑извращенцевфанатиков. Причём многие за счёт плагинов из программы для заметок делают звездолёт - с календарями, Kaban'ами, SQL запросами и всевозможными синхронизациями.

Вот и я решил попробовать писать в нём заметки и понять, действительно ли удобно так структурировать информацию.

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

Всё это с синхронизацией между компьютером и телефоном.

В какой-то момент она даже бэкапила все мои проекты до появления Postgresus'a.

Но вот заметки - была большая боль. Эдакий Apple Notes на минималках. Нет вложенности, нет нормального форматирования, нет связей и немного притормаживает.

За неделю использования Obsidian вижу следующие плюсы:

• всё работает очень шустро за счёт локального хранения и .md формата;

• добавляет спокойствие из-за хранения всего локально (даже если Obsidian умрёт — все файлы останутся);

• удобное форматирование и связи;

• удобно рисовать графики через Canvas и mermaid диаграммы (как PlantUML, но для .md);

• я начал структурировать всё, что читаю или узнаю.

Пока не нравится:

• не хватает AI с автокомплитом/автофиксом (как в Cursor'e);

• хотелось бы в заметки вставлять Google таблицы.

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

Потом посмотрю, какие всё-таки плагины стоит затянуть, и снова вернусь с отчётом в канал.

---

Мой Telegram канал про разработку.

Практически каждый день я читаю и узнаю что-то новое про разработку. Решил начать вести посты в формате "Я узнал о... (какой-то факт)"

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

---

Я узнал о... #1: FinOps

Задумка FinOps заключается в том, что мы начинаем считать расходы на DevOps и инфраструктуру в компании. Чтобы потом всё это счастье оптимизировать и сэкономить (в идеале, спрогнозировать расходы и риски).

Само название меня немного насмешило, потому что взяли "Ops" и добавили к нему другой префикс, чтобы выглядело солиднее

Стартапы очень любят таким же образом добавлять слово "Tech" ко всему подряд. Началось с EdTech и понеслось... AgroTech, FoodTech, PetTech, SleepTech, SexTech, HrTech.

Возвращаясь к сути: FinOps - это когда на уровне компании мы перманентно мониторим инфраструктуру, её загрузку и расходы, а затем ищем способы оптимизации.

McKinsey говорит, что от ~20% расходов на инфраструктуру в бигтехах уходят впустую. Следовательно, раз это нижняя планка, в среднем можно брать ~30%.

Например:

• сервера, которые взяли с запасом, и >50% ресурсов не используются (но оплачиваются);

• сервера для тестировщиков и стейджинга, которые мы купили и забыли про них;

• прожорливые сервера у проектов, которые не особо-то рентабельны (и стоит подумать уже об оптимизации кода).

Контроль делается за счёт того, что:

1. Мы начинаем в целом считать инфраструктуру, чтобы понимать, что в компании есть;

2. Затем мы начинаем мониторить утилизацию инфраструктуры, чтобы находить простаивающие ресурсы;

3. Каждый инстанс закрепляем за конкретной командой или человеком, чтобы посчитать ROI этой команды в контексте инфраструктуры.

Дополнительный бонус: CTO проще объяснить фин. директору, куда и зачем мы платим, и сколько примерно денег потребуется на следующий период.

Есть софт, чтобы считать инфраструктуру в гетерогенных облаках. Есть Kubecost, который умеет считать расходы в k8s. Есть разные опции в Terraform, чтобы считать стоимость инфраструктуры.

Даже есть подходы, когда инстанс нельзя использовать, пока не добавишь его в директорию всех инстансов компании. Но как это всё использовать - пока не вникал. Просто теперь знаю, что такие опции есть

Когда это нужно?

Пока расходы меньше $30к/мес. - должно хватать гугл-таблицы и зоркого взгляда CTO/DevOps'а. И дружеского вопроса команде: - "А зачем нам это?".

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

---

Мой Telegram канал про разработку.
Мой open source проект для бекапа PostgreSQL - GitHub.

Как я использую ИИ в разработке

Последний год я активно использую ИИ в разработке (особенно рутинных задачах): сначала ChatGPT 4o стал достаточно умным и подсказывал куски кода. Потом я освоил GitHub Copilot в VS Code (Go и TypeScript) и Inteliji IDEA (Java). А последние полгода пишу в основном в Cursor IDE.

Cursor IDE мне очень сильно понравился своим автокомплитом. Он не просто подставляет автодополнение, а умеет переписывать большие куски кода в разных частях файла.

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

И тут мой мозг начал взрываться! Агентский режим Cursor'a и интеллект ChatGPT o3-mini-high творят чудеса. В типовых задачах — это жуткая экономия времени.

(Пока писал пост, Open AI выпустили полноценную o3 и o4-mini-high 🤯).

Как я понял, Cursor + Claude 3.7 действуют по следующему алгоритму:

1. Проходит по исходникам, собирает контекст и паттерны.

2. Залезает в исходники библиотек и смотрит их код.

3. Если сильно нужно — бегает в интернет и обкашливает вопросики там.

4. Вносит изменения в код.

5. Смотрит ошибки линтеров и компиляции (!!!).

6. Ещё раз исправляет код и, если нужно, снова бегает по исходникам и библиотекам.

7. Говорит, что сделал и подсвечивает измененные куски кода.

На видео выше записал, как решаю задачу таким способом.

Задача: есть код, который принимает события от Telegram. В него нужно добавить поддержку новых событий и обновить DTO.

Cursor смотрит в интерфейс, что нужно добавить. Затем смотрит в библиотеку, какие там модельки. Обновляет код. Сам фиксит ошибки, если есть. Так ещё и говорит: "DTO и так нормальные, их трогать не буду". Красота!

К сожалению, как" вайб кодить" — я пока не понял. Потому что:

• весь код нужно сильно перепроверять;

• на задачах с весомой бизнес логикой получается фигня;

• пограничные кейсы не обрабатываются;

• тесты для чего-то больше CRUDов получаются с тоннами шаблонного кода, мало переиспользования;

• если файлов сильно много и задача в духе "пройдись по паре сотням файлов и поменяй что-то", Cursor начинает галлюцинировать и выдавать фигню.

Итого: сейчас ИИ мне сильно экономит время на шаблонных и рутинных задачах. Особенно, если задача не выходит за рамки 2-3 файлов и в проекте всё ок с тестами.

Условно, я делаю на 10%-20% меньше рутинной работы, которая раньше могла отнимать 2-3 часа в день.

Что-то комплексное или "написать проект с ИИ, не смотря код" — пока не получается (как минимум, пока что).

Но, в любом случае, уметь использовать ИИ потихоньку становится must have навыком для среднестатистических разработчиков. Разумеется, если используется не редкий язык, не специфическая сфера (типа написание ОС, где недостаточно обучающих данных) или не что-то критичное (медицина, ядерка и т.д.).

---

Если вам понравился пост или оказался полезным, поставьте, пожалуйста лайк ❤️. Это мотивирует делиться опытом из разработки. И, как полагается, у меня есть Telegram-канал, в котором я рассказываю про разработку, развитие SaaS-сервисов и управление IT проектами.

Как мы сокращали количество запросов по фичам в API

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

Одна из основных сущностей в коде — это BotUser. То есть пользователь, который появился в приложении (зашёл хотя бы раз), имеет имя и Telegram ID

За ~полгода проекта у нас добавилось много фич, привязанных к пользователю. Практически все сопоставляются 1 к 1 по ключу User ID. Например, квизы, бонусные дни, купленные страницы, купленный карточки апгрейдов, тариф и т.д.

Раньше для каждой новой фичи мы добавляли новый запрос в API с фронтенда. И вот мы заметили, что на каждый заход пользователя стало уходить >10 запросов в API ⚠️.

Примерно вот так:

GET /users/user
// Response
{
  "tgUsername": ...,
  "tgId": ...,
  ...
}

GET /users/features/quizzes/completed
// Response
{
  "completedQuizzes": ...,
}
   
GET /users/features/pages/bought
// Response
{
  "boughtPages": ...,
}
   
GET /users/features/rates/rate
// Response
{
  "userRate": ...,
}

При этом, на каждый запрос мы проверяли авторизацию. В Telegram это делается с помощью хеша от Telegram + проверка подписи токеном бота

Следовательно, на каждый запрос мы делали JOIN пользователя, брали бота (сущность Bot) из кэша и мэтчили подпись (+ логгировали). Это лишняя нагрузка

Сейчас подсобрали все фичи в один запрос. Теперь, на каждый заход пользователя получается только один GET /app/account/data, который возвращает данные пользователя вместе с данными фичей:

GET /app/account/data

// Response
{
  ...
  "user": ...,
  "completedQuizzes": ...,
  "boughtPages": ...,
  "currentRate": ...,
  ...
}

За одно перепроверили, что:

• не подгружаем связанные сущности, где не нужно (one-to-one, one-to-many);

• если подгружаем сущности, всегда делаем это одним JOIN'ом (а не бегаем по 2-3 раза в БД, как любит делать Hibernate);

• берём общие часто запрашиваемые данные из кэшей.

Это позволило снизить нагрузку на сервер и БД. К посту прикрепляю график загрузки части наших серверов по CPU до и после оптимизации.

---

Если вам понравился пост или оказался полезным, поставьте, пожалуйста лайк ❤️. Это мотивирует делиться опытом из разработки. И, как полагается, у меня есть Telegram-канал, в котором я рассказываю про разработку, развитие SaaS-сервисов и управление IT проектами.