подборочка сертификатоа для архитекторов https://medium.com/@nvashanin/certificates-in-software-architecture-6b18e0102fe7 из всего списка заинтересовал лишь RedHat architect и то из-за нежной любви к инженерным статьям RedHat-а. Есть ли у вас что-то сверх списка? И есть ли какие-то российские сертификаты на тему?

вот уж удивительно не знать своих героев. К стыду своему, не знала что Single Responsibility Principle ввел не кто-нибудь, а Robert Martin, чью книгу Clean Architecture я так недолюбливаю. Возможно, настала пора пересмотреть свои взгляды и перечитать книгу. А вот и оригинальная заметка в блоге Uncle Bob-а про SRP https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html

Open-source утилита для построения DAG диаграм по трейсам Jaeger (трейсинга распределенных систем) и нахождения критического пути. И, главное, вот уверена, что не только uber такое делает, что слишком распространенная задача, но взять на себя расходы и опубликовать в паблик код - крутое начинание. Для всех, кому важен перформанс его распределенной/микросервисной системы. https://eng.uber.com/crisp-critical-path-analysis-for-microservice-architectures/

Обширная коллекция API Guideline-ов для вдохновения при написании своего собственногго гайда https://apistylebook.com/design/guidelines/

Разбор unavailability инцидента в github. Поучительно и всего 4 минуты на чтение. https://github.blog/2021-12-01-github-availability-report-november-2021/

коротенькая статья о простом (но и dummy) тестировании производительности сервиса. Правда, не могу придумать реальных случаев, когда такой подход востребован. Серьезные системы имеют и стресс-тесты и прикрученные графаны, которые и mean померяют, и персентили нарисуют. А простым системам производительность и масштабируемость не важна. Но поделюсь все же ссылкой - вдруг пригодится https://developers.redhat.com/articles/2021/12/16/elegant-way-performance-test-microservices-kubernetes

Архитектурное пожелание на наступающий год. Желаю нам с вами, чтобы все наши прекрасно проработанные планы и спеки реализовывались в полной мере. Чтобы мы чаще искали лучших из хороших решений, нежели приемлемых из плохих. Чтобы 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/ И вроде тема-то простая, но так иногда сложно ее объяснить. В общем, руки чешутся применить.