Как архитектор-консультант в Red Hat, я имел возможность поработать над множеством проектов для наших клиентов. У каждого из них есть свои особенности, которые, однако, имеют некоторые общие черты. Большинство клиентов хотят знать, как скоординировать запись в несколько систем одновременно. Ответ на этот вопрос обычно включает подробное объяснение двойной записи, распределенных транзакций, современных альтернатив, а также возможных сценариев сбоев и недостатков каждого подхода. Как правило, именно в этот момент заказчик понимает, что разделение монолитного приложения на микросервисы - долгий и сложный путь, обычно требующий компромиссов.

Уже три года, как мы постепенно передаем солюшн-архитектуру в команды разработки. Приходится часто объяснять, как сделать архитектурное решение коллегам, которые раньше подобными вещами не занимались. Отсюда родилась идея этой статьи – поделиться опытом, который сложился у меня и моих коллег за 10 лет практики. Важная часть этого опыта – шаблон архитектурного решения с пояснениями как его заполнять и почему именно так. По сути, шаблон - это структура необходимых знаний. Если вы нашли ответы на все вопросы шаблона, значит вы продуманно подошли к созданию архитектуры. А еще, сделали хороший документ, с которым удобно работать.

Статья расскажет, как правильно оформить ваши мысли, и что должно содержать качественное архитектурное решение. Статья не научит делать архитектуру.

Статья будет полезна:

• Аналитикам, тимлидам, программистам, которые уже делают или собираются делать архитектурные решения;

• Архитекторам, чтобы улучшить качество выпускаемых документов;

• Главным архитекторам с целью посмотреть «а как там у них».

Это гостевая публикация от Пэдди Байерса (Paddy Byers), сооснователя и технического директора Ably  — платформы для стриминга данных в реальном времени. Оригинал статьи опубликован в блоге Ably.

Люди хотят быть уверены в надежности используемого сервиса. Однако в реальности отдельные компоненты неизбежно отказывают, и у нас должна быть возможность продолжать работу, несмотря на это.

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

Для начала дадим несколько определений:

Надежность — cтепень того, насколько пользователи могут положиться на продукт или сервис для решения своих задач. Доступность и устойчивость являются видами надежности.

Доступность — степень готовности продукта или сервиса к эксплуатации по требованию. Это понятие часто сcодят к обеспечению необходимого излишка ресурсов с учетом статистически независимых отказов.

Устойчивость — cпособность продукта или сервиса соответствовать заявленным характеристикам в процессе использования. Это значит, что система не просто готова к эксплуатации: благодаря дополнительным мощностям, предусмотренным в ходе проектирования, она может продолжать работать под нагрузкой, как и ожидают пользователи.

Отказоустойчивость — способность системы сохранять надежность (доступность и устойчивость) при отказе отдельных компонентов или сбоях в подсистемах.

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

Статья содержит вводную информацию о резервировании и других возможностях обеспечения отказоустойчивой работы серверов и прочего оборудования ИТ-инфраструктуры предприятия.

Мы всегда надеемся, что оборудование и инфраструктура будут работать чётко, надёжно, и без поломок. Особенно это важно там, где неисправности приводят к остановке бизнес–процессов и как следствие – финансовым и репутационным потерям. Как минимум, эти потери складываются из оплаты сотрудников за время простоя (пока они ждут восстановления работы системы), и упущенной за это время прибыли. К этому можно добавить суммы, затраченные на сам ремонт и восстановление системы (покупку исправных комплектующих, оплату работ по установке и замене, и т.п.). Сумма убытков может быть достаточно большой; в некоторых случаях простой может привести к непоправимым последствиям – вплоть до исчезновения бизнеса. Это является поводом задуматься о том, как можно избежать остановки работоспособности.

❓Как проектировать системы, которые будут толерантными для различного вида отказов и ошибок?

Что такое отказоустойчивость и стабильность?

Под отказоустойчивостью будем понимать свойство системы, которое позволяет максимально сохранять работоспособность при отказе отдельных конкретных компонентов системы либо связанных систем и восстанавливать работоспособность системы при восстановлении отказавших компонентов или связанных систем. Давайте рассмотрим подробнее эти 2 момента:

1. Деградация работоспособности системы должна быть прямо пропорциональна "величине" отказа. То есть, если упал сервис, отвечающий за некую некритичную функциональность — вся система не должна при этом падать. Да, небольшой кусочек не работает, но это не влияет на стабильность остальной части функционала.

2. Стабильность системы предполагает самостоятельного восстановления работоспособности после сбоя как компонентов системы, так и всей системы в целом. К примеру, если пропадала сеть на некоторое время — то у стабильных систем после восстановления подключения все компоненты продолжат работать и данные вернутся в консистентное состояние без ручного вмешательства со стороны команды эксплуатации.

Масштабирование базы данных через шардирование и партиционирование

Денис Иванов (2ГИС)

Всем привет! Я достаточно давно в разработке и мне приходилось видеть разные вариации гибких методологий управления проектами. Чаще всего я встречал такую картину: вроде есть спринты, дейли, иногда даже демо, отчеты, но все равно, получив набор фичей от бизнеса, команда не могла сказать достаточно быстро (где-то в течение недели), сколько времени ей потребуется на реализацию. Со временем я пришел к своей спринтовой модели, которая позволяет моей команде довольно точно и быстро давать оценку трудозатрат, что в итоге приводит к успешному попаданию в дату релиза.

За последние несколько лет я значительно изменил свой подход к проведению технических собеседований. Если когда-то (лет 7 назад) я мог весело и задорно интервьюировать джавистов два часа, то на текущей позиции у меня нет столько времени на каждого кандидата. При наличии 4 открытых позиций и с результативностью 10% (примерно 10% кандидатов проходят собеседование и готовы принять оффер), получается, что мне нужно провести порядка 40 собеседований. Если тратить хотя бы по часу на собеседование, то это дополнительные 40 рабочих часов, которые где-то надо найти. Плюс накинуть 10 минут на переключение между задачами, получается ещё 400 минут (~6.5 часов).

Поэтому я задумался над вопросом повышения эффективности собеседований.

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

Стремясь к повышению производительности базы данных, вы можете столкнуться с ситуацией, когда оптимизации и настройки уже недостаточно. Если вы не можете заменить движок БД, а для настройки параметры рабочей нагрузки больше нет возможностей — базу данных придется масштабировать. Делать это руками долго и нецелесообразно, но и у автоматизации процессов масштабирования есть свои подводные камни.

Это перевод статьи Дмитрия Костика и Миколы Моржан из Percona. С их помощью посмотрим, в какой степени можно автоматизировать горизонтальное масштабирование баз данных MongoDB, MySQL и PostgreSQL в Kubernetes и как это сделать?

Меня зовут Алексей Шарапов. Я занимаюсь построением процессов и командами в AkBars Digital. В нашем формате работы девопсы погружены в продуктовые команды, то есть у нас не сервисная модель. Еще я разрабатываю наше внутреннее облако, автоматизирую и запускаю проекты на Kubernetes. В статье рассмотрим оба аспекта моей работы: немного поговорим про командное взаимодействие и немного про инструментарий.

Одни из самых частых вопросов от инженеров, которые я слышу: «Есть проект 10 микросервисов, пора ли запускать его в K8s или нет?» или «У нас есть проект, мы хотим поехать в K8s — надо ли нам это делать или нет?». Мы много занимались его решением, в том числе, с компаниями в формате аудита. Из этого опыта и родилась статья.

За 21 год существования в SuperJob разработали три версии реализации API для интеграций с бэкендом. Во время разработки последней они решили пересмотреть подход к версионированию. Сейчас в актуальной реализации порядка 379 эндпойнтов, более 900 моделей сущностей и 11 поддерживаемых мажорных версий. Когда проект развивается, вместе с ним меняются и требования к API, а значит неизбежно нарушение обратной совместимости.

Опытом решения этой проблемы поделился Антон Золотилин из SuperJob. Вы увидите самые распространенные решения проблемы версионирования web-API и подход, который реализовал у себя SuperJob. А в качестве бонуса узнаете, как это решение помогает значительно сократить рост затрат на тестирование версий с помощью Impact-анализа.

Наверное, каждый из нас задумывался о том, как было бы классно, если бы кондиционер сам включался, когда мы подходим домой. Однако для управления всеми устройствами либо используют готовое решение из облака, либо приходится заморачиваться с покупкой микрокомпьютера, чтобы умный дом не стал глупым без интернета :) Но нужен ли для этого микрокомпьютер, если наверняка в шкафу лежит запылившийся планшет или смартфон, который когда-то работал и с более требовательными приложениями?..

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

Ждать долго не пришлось, при обновлении на сервере PHP c 7.2 до 7.4 - мы получили страницу с описанием ошибки, вместо документации. Ошибка найдена в библиотеке, которую мы использовали для рендеринга UI документации. ПР на гитхабе был создан быстро, но провисел в статусе open почти неделю. После этого, тикет насчет документации пошел в работу.

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

Сегодня нам предстоит описать решение задачи по созданию классификатора текстовых документов. Шаг за шагом мы будем пытаться улучшить нашу модель. Давайте посмотрим, что же из этого получится.

Для решения нашей задачи снова используем язык программирования python и среду разработки Jupyter notebook на платформе Google Colab.

В работе понадобятся следующие библиотеки:

Пакет для фреймворка Laravel, который позволяет организовать управление древовидными комментариями. Используется симбиоз двух методов хранения иерархических структур — «Closure Table» и «Adjacency List».

Совместное применение методов «Closure Table» и «Adjacency List» позволяет: Минимизировать количество запросов к базе данных. Для извлечения ветки комментариев достаточно одного запроса, обеспечить высокую производительность, гарантировать целостность данных иерархи, работать с древовидными структурами без рекурсивных запросов.

Что нового в Laravel 8. Руководство по обновлению до новой версии. Laravel Jetstream. Пакетирование задач. Набор компонентов для Blade-шаблонов.