Практически каждый день я читаю и узнаю что-то новое про разработку. Формат "я узнал о... #" - это краткая выжимка идей, заметок и концепций, про которые я прочитал или узнал за неделю. За эту неделю я узнал про FinOps, Obsidian, DevOps фреймворк DORA и шрифт Google Sans. А ещё подумал о спорте и разнице между OLTP и OLAP нагрузкой.
Содержание
FinOps
Obsidian
DevOps фреймворк DORA
Шрифт Google Code Sans
OLAP и OLTP нагрузка
FinOps
Задумка FinOps заключается в том, что мы начинаем считать расходы на DevOps и инфраструктуру в компании. Чтобы потом всё это счастье оптимизировать и сэкономить (в идеале, спрогнозировать расходы и риски).
Само название меня немного насмешило, потому что взяли "Ops" и добавили к нему другой префикс, чтобы выглядело солиднее. Стартапы очень любят таким же образом добавлять слово "Tech" ко всему подряд. Началось с EdTech и понеслось... AgroTech, FoodTech, PetTech, SleepTech, SexTech, HrTech.
Возвращаясь к сути: FinOps - это когда на уровне компании мы перманентно мониторим инфраструктуру, её загрузку и расходы, а затем ищем способы оптимизации.
McKinsey говорит, что от ~20% расходов на инфраструктуру в бигтехах уходят впустую. Следовательно, раз это нижняя планка, в среднем можно брать ~30%.
Например:
сервера, которые взяли с запасом, и >50% ресурсов не используются (но оплачиваются);
сервера для тестировщиков и стейджинга, которые мы купили и забыли про них;
прожорливые сервера у проектов, которые не особо-то рентабельны (и стоит подумать уже об оптимизации кода).
Контроль делается за счёт того, что:
Мы начинаем в целом считать инфраструктуру, чтобы понимать, что в компании есть;
Затем мы начинаем мониторить утилизацию инфраструктуры, чтобы находить простаивающие ресурсы;
Каждый инстанс закрепляем за конкретной командой или человеком, чтобы посчитать ROI этой команды в контексте инфры
Дополнительный бонус: CTO проще объяснить фин. директору, куда и зачем мы платим, и сколько примерно денег потребуется на следующий период.
Есть софт, чтобы считать инфраструктуру в гетерогенных облаках. Есть Kubecost, который умеет считать расходы в k8s. Есть разные опции в Terraform, чтобы считать стоимость инфраструктуры.
Даже есть подходы, когда инстанс нельзя использовать, пока не добавишь его в директорию всех инстансов компании. Но как это всё использовать - пока не вникал. Просто теперь знаю, что такие опции есть.
Когда это нужно?
Пока расходы меньше $30к/мес. - должно хватать гугл-таблицы и зоркого взгляда CTO/DevOps'а. И дружеского вопроса команде: - "А зачем нам это?".
Когда расходы >$30к/мес. и оперативной памяти ответственного лица не хватает - можно начинать думать об автоматизации сбора метрик. Иначе до этого момента автоматическое сведение метрик воедино рискует просто не окупиться.
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 таблицы.
Все советуют попользоваться хотя бы месяц, прежде чем делать первые выводы. Так что месяц поиспользую. Потом посмотрю, какие всё-таки плагины стоит затянуть, и снова вернусь с отчётом.
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'ом.
Критерии (как быстро поднимаем прод):
отлично: меньше часа;
хорошо: меньше дня;
средне: меньше дня;
плохо: больше дня.
Когда это нужно?
Для себя я выделил три критерия, когда эти метрики имеет смысл считать:
Когда есть конкретный продукт в активной стадии развития с постоянной командой хотя бы из 3-5 разработчиков. Т.е. это не что-то, что получает несколько фич в месяц или находится в стадии активного саппорта.
Когда компания большая, в которой появилось много команд с продуктами и нужно выстроить хоть какое-то понимание в среднем по компании. Вот тут, кстати, важно не начать погоню за метриками, т.к. все внутренние проекты живут в своём темпе. Нельзя выставить одинаковые метрики всем поголовно в качестве KPI.
Когда СТО\CIO нужны хоть какие-то метрики для отчётности. Чтобы объяснить инвесторам или нетехнической части C level'a, что в компании или команде хороший DevOps процесс (или, наоборот, плохой).
DORA метрики измеряются через GitLab или почти любую другую систему CI \ CD. GitLab умеет считать всё это из коробки. За исключением, наверное, падения прода (что тоже можно добавить вручную или вебхуками \ alert manager'ами).
Шрифт Google Code Sans
Так получилось, что я никогда особенно не запаривался из-за настроек IDE и шрифтов. Главное, чтобы шрифт был моноширный, а остальное без разницы.
По началу это был Eclipse не помню с каким шрифтом. Потом много лет JetBrains Mono, который стоял по умолчанию в IDEA. В какой-то момент я начал активно использовать VS Code. В нем стоял стандартны шрифт Consolas. Я к нему настолько привык, что поставил во все IDE.
Но несколько недель назад увидел обсуждение шрифтов на Хабре.
Оказалось, существуют шрифты, которые придумывают специально под разработку. В чём детали я так и не понял (помимо лигатур). Но суть в том, что они сбалансированны так, чтобы наши глаза и мозг тратили минимум усилий для захвата контекста и понимания происходящего.
Один из комментариев был про Google Code Sans. Его выложили в открытый доступ примерно год назад.
Я решил попробовать, установил везде и... оказалось очень удобно и визуальном приятно.
Со стороны может показаться мелочью, но я смотрю в код большую часть суток и, когда код аккуратнее и понятнее - работать тоже чуточку приятнее.
Рекомендую попробовать (разработчиской части тех, кто читает этот текст).
OLAP и OLTP нагрузка
Про виды нагрузки я знаю давно. Просто решил упрощенно рассказать, как это понимаю.
При работе с базой данных нагрузку обычно делят на два типа: OLTP и OLAP.
OLTP нагрузка (On Line Transaction Processing) - это когда много мелких операций (транзакций) практически в режиме реального времени. Которым, как правило, требуется ACID.
Примеры операций (утрированно):
зарегистрировать пользователя;
запросить информацию об аккаунте;
сделать банковскую операцию;
увеличить игровой баланс;
обновить название товара;
получить список покупок за пользователя; и т.д.
Это тот режим, в котором работают из коробки PostgreSQL, MySQL, MongoDB и другие стандартные базы данных. Такой формат данных даёт максимальную скорость при высокой надёжности (и поддерживает ACID).
Данные при OLTP нагрузке хранятся в строках. Для ускорения поиска создаются индексы, которые ускоряют поиск нужных строк.
Пример записи данных:
user_id, order_id, status
(101, 5001, paid)
(102, 5002, pending)
(101, 5003, shipped)
...
(103, 5004, paid)
(104, 5005, canceled)
(101, 5006, paid)
(105, 5007, refunded)
...OLAP нагрузка (On Line Analytical Processing) - это когда мы пишем очень большой объём данных (терабайты сырых данных), при этом запрашиваем их относительно редко и с целью анализа на большом промежутке времени.
Например:
считаем показатели по продажам за прошлый год;
считаем LTV пользователей в разрезе по продуктам;
считаем корреляцию между временем суток и посещением страниц приложения пользователями во время акции;
записываем аналитику по кликам пользователей на нашем сайте;
записываем и анализируем телеметрию.
Такой формат хранения поддерживают колоночные (иногда их называют "аналитические") базы данных по типу ClickHouse, TimescaleDB и т.д.
Кстати, для PostgreSQL и OLTP баз есть плагины и расширения, которые добавляют поддержку такого формата работы с данными.
Сами данные хранятся в колонках:
(101, 102, 101, ... 103, 104, 101, 105, ...)
(5001, 5002, 5003, ... 5004, 5005, 5006, 5007, ...)
(paid, pending, shipped, ... paid, canceled, paid, refunded, ...)При этом данные оптимизируются за счёт сортировки. Иногда необходимое место для хранения можно ужимать в десятки и сотни раз за счёт оптимизации повторяющихся данных. Концептуально это выглядит так:
user_id = (101, {start: 0, count: 2}, 102, {start: 2, count: 1}, ...)
order_id = (5001, {start: 0, count: 1}, 5002, {start: 1, count: 1}, ...)
status = (paid, {start: 0, count: n}, pending, {start: k, count: m}, ...)Ещё есть базы данных, которые поддерживают одновременно и OLAP, и OLTP виды нагрузки.
ROLAP (Relational Online Analytical Processing) - это когда одновременно пишем и в OLTP, и строим индексы поверх важных данных для OLAP запросов. Сразу всё и туда, и туда не пишем, потому что скушаем слишком много места.
Такой вид нагрузки поддерживают PostgreSQL, Oracle и MySQL, если к ним добавить плагины и надстройки.
HTAP (Hybrid Transactional / Analytical Processing) - это когда база из коробки (без надстроек) умеет одновременно и в OLTP, и OLAP. Достигается или за счёт одновременной записи в строки и колонки, или за счёт оптимизаций в RAM.
Из БД, которые так умеют, я слышал только про CockroachDB.
Лично я не знаю кейсы, когда нужно брать ROLAP или HTAP базы. Только слышал, что такое бывает полезно в SAP, 1C и ERP системах.
В остальном для всего, что не аналитика - я беру PostgreSQL. Всё, что аналитика - или пытаюсь засунуть в PostgreSQL, если маленький объём данных. Или ClickHouse, если данных действительно очень много, а запросы действительно аналитические.
Может быть интересно:
P.S. Ещё у меня есть: Telegram канал, если вдруг интересны мои заметки о разработке.