Архитектурное пожелание на наступающий год. Желаю нам с вами, чтобы все наши прекрасно проработанные планы и спеки реализовывались в полной мере. Чтобы мы чаще искали лучших из хороших решений, нежели приемлемых из плохих. Чтобы budget-owner-ы отзывались на наши инциативы и меньше сомневались в наших рассчетах. И тогда все больше было бы в мире хорошо сделанных, качественных продуктов и сервисов.

На хабре опубликовала статью по выявлению и оценке технического долга. Статья (а точнее доклад) появился как ответ на вопрос «что делать, когда техдолг снижает скорость разработки, все на что-то жалуются, а с чего начать неясно?» https://habr.com/ru/company/oleg-bunin/blog/645349/

Статья о том, как Netflix перформанс тесты в ci встроили. https://netflixtechblog.com/fixing-performance-regressions-before-they-happen-eab2602b86fe что интересно: они отказались от статических величин threshold-ов для тестов и стали смотреть на аномалии и changepoint-ы. Про аномалии-то понятно, а changepoint стал чем-то новым для меня. Ну и будоражат истории о том, как ci из красного стал зеленым.

Серия статей Tinder от 2019ого года о том, как они делали geo-shard. https://medium.com/tinder-engineering/geosharded-recommendations-part-1-sharding-approach-d5d54e0ec77a https://medium.com/tinder-engineering/geosharded-recommendations-part-2-architecture-3396a8a7efb https://medium.com/tinder-engineering/geosharded-recommendations-part-3-consistency-2d2cb2f0594b

Четкое и ясное описание replicated log на базе Raft для синхронизации состояния в распределенной системе. Кажется, это первый раз когда до меня на самом деле дошло, как оно внутри устроено со всеми corner cases (до этого довольствовалась описанием концепта, но на кончиках пальцев понимания деталей не хватало). https://martinfowler.com/articles/patterns-of-distributed-systems/replicated-log.html Но это еще не все - этот паттерн лишь часть коллекции Distrubuted systems patterns, которые Unmesh Joshi публикует в блоге Фаулера https://martinfowler.com/articles/patterns-of-distributed-systems/ Кстати, мог бы быть неплохой вопрос на собеседовании - рассказать базовый алгоритм, а дальше предложить кандидату фантазировать о всех corner case в условиях что любой из серверов любое количество времени может быть unavailable. Не нужно чтобы ответил все, но вопрос насколько богато воображение.

Сравнение gRPC с OpenAPI https://www.redhat.com/en/blog/comparing-openapi-grpc c бонусом в виде подборки статей внутри. Хотя мне так и не хватает проекта, где один и тот же магазин книг/petstore будет представлен в трех форматах - gRPC, OpenAPI, GraphQL. Если знаете, поделитесь

Поделюсь ссылкой на понравившийся доклад. Точнее, что еще ценнее, ссылкой на его отшлифованную расшифровку https://habr.com/en/company/oleg-bunin/blog/594179/ Доклад, в общем-то, не открывает америку, не презентует новую концепцию. Но при этом будет полезен тем, кто планирует переезд в микросервисы или просто симпатизирует.

И опять я с long-read-ами. Наткнулась на прикольную статью 2002ого года, оценивающую применимость и актуальность security evaluation, проведенного в 1974ом году над Multics. Кто не в курсе, то Multics - это отец Unix-а и через то прародитель большинства современных операционных систем. https://www.acsac.org/2002/papers/classic-multics.pdf Эх, и кто из Intel-а придумал растить стек не в том направлении? А то могли бы избавиться от ROP-а. Сам security evaluation report значительно длиннее, но интересен чтение с точки зрения формата и процедуры Security evaluation https://seclab.cs.ucdavis.edu/projects/history/papers/karg74.pdf

С курса по теоретическому инфобезу вынесла в числе прочего интересный вывод про избыточность. Чаще всего, говоря про избыточность мы подразумеваем redundancy (active/passive/spare) и представляем дополнительные копии сервиса/данных и думаем о защите от неожиданного выхода из строя одной копии. Но есть еще избыточность, которая diversity, заключающаяся в многообразии имплементаций и коллегиального решения на базе разных источников. Цель diversity - уберечься от ошибок каждой имплементации, и используется она в авионике и других life-critical системах. Redundancy используется для достижения availability, а также security (помним ведь cia = confidentiality, integrity, availability). Diversity нужна для safety и надежности системы. Но вот что любопытно: diversity - это один из редких моментов, где safety противоречит security, ведь обычно безотказное и надежное ПО - это еще и ПО без weakness/vulnerabilities, то есть безопасное ПО. Но использование разных имплементаций, хоть и снижает риск ошибки в принимаемом решении, увеличивает кодовую и элементную базу, а значит увеличивает вероятность эксплуатируемой ошибки. И по принципу weakest link снижает секурность всей системы. Такое вот занятное наблюдение

Знакомые стартовали новый канал по недетскому программированию, с обсуждениями тонкостей си, компиляторов, лоу-левел и хай-тек. Зашёл их разбор хоббийных ОС. https://t.iss.one/justcodeit_channel/7

И снова размышление о версионировании REST API. Казалось бы, его место в URI и спор может быть только о том говорить api/v1 или api/1. Но возникают все новые варианты. Вариант 1 - версионировать тела запросов, то есть добавить версию в json. Недостатки: nginx/apigee не сможет роутить запрос на нужную версию инстанса, а значит несимпатичная compatibility логика оказывается в компоненте, увеличивая его сложность(и эту логику никто не любит ни писать, ни тестировать, ну и дальше вы понимаете). Вариант 2 - Microsoft-овский - версия в query parameters https://github.com/microsoft/api-guidelines/blob/vNext/Guidelines.md#12-versioning. Недостатки: routing по query params потребует их парсинга, что увеличит время процессинга; а кроме того усложнится клиент, ведь ему прийдется в явном виде каждый раз формировать query parameters (или надеяться что версия не поломается, а сколько людей не читают документацию). Вариант 3 - версия в header-е https://youtu.be/P0a7PwRNLVU . Routing получше, чем вариант 2, но сложность клиента опять же возрастает с теми же рисками что в варианте 2.

Вывод. Не ставить версию в URI могут только те команды, которые уверены либо в короткой жизни продукта либо в бессмертии технического лидера (или тотальной преемственности). Потому что клиенты будут забывать ставить версию, если их не насиловать на эту тему, а логика back-compatibility в компоненте постоянно будет источником багов. Да и зачем придумывать новое, когда есть понятное дефолтное для всех решение?

Ух ты и ах. Google-овские книги по SRE доступны онлайн. https://sre.google/books/ Конечно, самая главная здесь книга https://sre.google/sre-book/table-of-contents/ Нигде я больше не видела такого внятного размышления про разницу между SLA, SLO и SLI https://sre.google/sre-book/service-level-objectives/

Выбор удобной структуры данных для хранения статистики - одна из классических задачек system design собеседования или algorithm & structures секции общедевелоперского интервью. В отличие от многих других, задача имеет практическое применение. Итак, дано: есть сервис, исполняющий какую-то работу. вопрос: как собирать информативную статистику по производительности его работы. ответ: avg, min, max информативными не являются. первая часть ответа состоит в том, что нам нужны персентили и нужно скользящее окно за последние N минут/секунд/временных интервалов. вторая часть ответа - это как сделать не наивную имплементацию. Наивная имплементация чаще всего сводится к списку величин с popup-ом (ну и может aging). продвинутый ответ включает hdr histogramme, forward decay и t-digest. А дальше все ушли читать про те из структур, что не знали 🙂 И интересно, может у вас какой-то другой ответ на эту задачку?

На Techlead Conf в этом году задалось немало хороших докладов. Сейчас слушала доклад про интервью SRE - организация секции troubleshooting и кратенько про секцию system design. Товарищ предусмотрительно описал доклад в статье. https://apolomodov.medium.com/troubleshooting-interview-3690b40a3d77 делюсь. И ещё слайдик от него же на почитать (среди ссылок ещё одно видение sysDesign interview - https://apolomodov.medium.com/system-design-interview-at-tinkoff-7bd97c20d082)

Как же красиво делает некоторые процессы Google. И выдает наружу готовые материалы для того, чтобы провести workshop, а потом завести процесс у вас. Вот сейчас наткнулась на их раздатки по SLO https://sre.google/resources/practices-and-processes/art-of-slos/ И вроде тема-то простая, но так иногда сложно ее объяснить. В общем, руки чешутся применить.

Postman опубликовали обновление API Platform Landscape [1] с перечнем продуктов и трендов в мире API.

Ключевые тезисы оттуда:
1. Компании переходят к модели API-first
2. Гибридная архитектура и многооблачность
3. API как продукт
4. Взрывной рост продуктов API Gateway
5. Всё больше протоколов для API в активном использовании.
6. Всё больший сдвиг в сторону безопасности доступа к API.

Не все согласятся что экосистема API существует автономна, например, для меня это скорее часть экосистемы работы с данными, а Postman показывают её с выгодной для них стороны там где они лидеры, но, тем не менее, в части описанного, тренды изложены верно и сам обзор полезен.


Ссылки:
[1] https://blog.postman.com/2022-api-platform-landscape-trends-and-challenges/

#api

Слушала на днях старый доклад с Highload-а про отказоустойчивость. Кроме описания пары amazon кейсов 10-летней давности понравилась формула про “Маленький флот вызывает большой”: инициатирует передачу данных тот, у кого пропускная способность/количество инстансов меньше, иначе рискуем организовать отказ. И в целом размер "флота" можно было бы назвать универсальным критерием для выбора между push и pull моделью, если бы нас интересовал только сценарий отказа, без учета секурити, производительности и масштабируемости. В целом, неплохой доклад про проектирование систем на отказ и каскадные падения, если только не забывать про другие критерии и не брать решения as is, а понимать что все зависит от приоритетов QAS (quality attribute scenario).
https://habr.com/ru/company/oleg-bunin/blog/497332/

Читала статью Бишопа про robust системы. Статья-то хорошая с примерами, что может поломаться при имплементации очереди и как это предотвратить. https://nob.cs.ucdavis.edu/bishop/secprog/robust.html Но как же она проста по сравнению с моим любимым докладом от Алексея Миловидова про robustness ClickHouse-а. https://www.youtube.com/watch?v=ooBAQIe0KlQ&list=PLH-XmS0lSi_zTZrols83QSxI3Q96dSbBm&index=93 Вывод - простые пробои/фейлы можно предотвратить и на уровне простеньких систем. Это девиз про "нормально делай - нормально будет". Но для того, чтобы быть устойчивым и против редких событий требуется уже дополнительные харденинги, на которые далеко не всякая компания готова потратится.

Простые концепции даже при наличии corner case-ов могут значительно упрощать работу со сложными системами. Вот, например, правило 2х от Chromium https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md : никогда не совмещайте (а) код написанный на небезопасных языках, (б) код не из песочницы, (в) недоверенный ввод. Это звучит просто, запоминается как CAP-теорема или триада ремонта("быстро, качественно, недорого - выбирай два из трех"). И имеет теоретическую базу: ребята проанализировали последние уязвимости проекта, откатегоризировали их и придумали как заткнуть основной источник ошибки. Очаровала меня аккуратность такого подхода. То, чего architecture hoisting добивается путем злостной машинерией, инженеры Chromium-а добились аккуратной теорией, заложенной прямо в мозг.

Воодушевляющая пятничная аналитика о падении больших ИТ проектов https://spectrum.ieee.org/lessons-from-a-decade-of-it-failures Читая эту статью, постоянно вспоминала "Путь камикадзе"(Death march) Йордана и его правила выживания в смертельных проектах. Берегите себя

Цитата дня: "The greatest limitation in writing software is our ability to understand the systems we are creating". больше вдохновения в видео John Ousterhout https://www.youtube.com/watch?v=bmSAYlu0NcY, который написал курс по software design для Стендфорда. Размышления об управлении сложностью на уровне кода весьма здравые, особенно когда добавляется измерение горящих дедлайнов.