Ричард Кроули из Slack рассказал про то, как они тестируют устойчивость сервисов к ошибкам — "Disasterpiece Theater: Slack’s process for approachable Chaos Engineering".

Для тестирования fault-tolerance команда Slack следует процессу, который они назвали "театром маленьких разрушений". В самом начале этого "представления" определяется, какая часть системы будет тестироваться, составляется план отключения и восстановления. Документируются гипотезы того, как будет себя вести поломанная система. Вот пример из статьи: "Отключение мастера MySQL приведёт к повышению времени ответа на 20 секунд для запросов, которые зависят от этой базы, для других запросов повышения таймингов не будет, ожидается менее 1000 неудачных запросов, которые будут заретраены клиентами”. Затем провоцируется поломка в тестинге. Гипотезы сверяются с тем, что произошло в реальности и делаются выводы. Если в тестинге, всё прошло хорошо, поломка провоцируется в проде. В статье есть пара примеров того, какие проблемы были обнаружены благодаря такому подходу.

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

https://slack.engineering/disasterpiece-theater-slacks-process-for-approachable-chaos-engineering-3434422afb54

#devops #backend #testing

Прочитал статью Артура Басака — "Должен ли фронтенд разработчик уметь писать бэкенды?"

Артур пишет про то, что граница между фронтендом и бэкендом очень размыта. На западе под фронтендом понимается работа с CSS/HTML. У нас чаще всего по-другому — под фронтом понимается JavaScript, а владение CSS/HTML подразумевается как само собой разумеющееся.

С другой стороны фронтенд и бэкенд сильно переплетены друг с другом — для разработки сложных вещей требуется понимание и того, и другого. Например, в микросервисных архитектурах может использоваться Backend For Frontend (BFF) — сервис, который собирает и подготавливает данные для рендеринга или передачи на клиент. В компаниях BFF обычно разрабатывают фронтенд-разработчики.

В конце статьи есть хорошая мысль: любая технология — это всего лишь инструмент. Чем большим количеством инструментов владеет разработчик, тем больше он ценится на рынке.

#musings #backend #frontend

https://medium.com/front-end-in-regions-grodno/front-back-e1198c42d673

Наткнулся в твиттере на отличный тред Криса Ачарда про DNS — "DNS Record crash course".

Если вам приходилось работать с доменными именами, то скорее всего вы знаете про существование DNS-записей A, AAAA, CNAME, MX и т.п. В треде Крис очень кратко рассказывает про назначение этих записей и их особенности. Например, если был определён CNAME для поддомена, тогда не получится определить другие запись для того же самого поддомена.

Очень рекомендую почитать тред — там всё написано без воды и по делу. Must read для тех, кто только начинает заниматься web-разработкой.

#dns #backend

https://twitter.com/chrisachard/status/1188870256971915265?s=20

Кэти Хемпениус на сайте web.dev опубликовала гид по решению проблем, возникающих из-за большого траффика — "Fix an overloaded server".

Если на сайт внезапно пришло большое количество пользователей, и он перестал осиливать нагрузку, то надо предпринять четыре шага:
1. Оценка — поиск причин отказов: CPU, IO, память, сеть.
2. Стабилизация — быстрые фиксы, которые позволят вернуть сайт к жизни: rate limiting, кэширование, отключение фич, которые особо сильно не влияют на бизнес-метрики, но которые потребляют ресурсы.
3. Улучшение — использование CDN и балансеров, добавление железа, использования сжатия ресурсов
4. Мониторинг — использование средств мониторинга показателей по перцентилям, чтобы средние значения не могли скрыть проблемы, которые возникают не у всех пользователей.

Статья полезная, рекомендую почитать.

#performance #backend

https://web.dev/overloaded-server/