Свежий взгляд на HighLoad 🚀

Как правило, никто не называет систему высоконагруженной до тех пор, пока она стабильно работает . #Хайлоад – это ситуация недостатка в ресурсах, возникающая при росте нагрузки. На примере любой системы, испытывающей высокую нагрузку, подразумевается, что она работает на пределе своих возможностей. И вероятность отказа в обслуживании высока.

Основные советы при проектировании высоконагруженных приложений:

1. Микросервисы предпочтительнее монолита.
2. Горизонтальное масштабирование предпочтительнее вертикального.
3. Асинхронное взаимодействие удобно для конвееров обработки, синхронное – для систем с гарантированным уровнем задержки.
4. Разделяйте систему по уровням (tiers) и стремитесь к избыточности (redundancy) в каждом из уровней.
5. На уровнях обработки бизнес-логики стремитесь к stateless-архитектуре. Состояния выносите в отдельное персистентное хранилище.
6. Кешируйте запросы и статику, но помните о консистентности данных.
7. Масштабируйте data tier (базы данных) посредством шардирования и/или репликации.
8. Обеспечивайте поддержку нескольких независимых дата-центров.
9. Используйте инструменты логирования, мониторинга и автоматизации (CI/CD).

Увлекательный лонгрид про HighLoad 🙂

Как построить успешную информационную систему: подходы и практики

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

Мы рассмотрим три определяющих вопроса к построению большинства систем:

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

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

3. Удобство сопровождения. Разработчикам и специалистам технической поддержки должна быть обеспечена возможность эффективной работы с системой.

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

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

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

Увлекательный лонгрид здесь 🙂

Future retrospective 😱

Возникало у вас ощущение после выполнения задачи, что можно было сделать лучше? А часть и вовсе пропустить, сделав ход конем? Что-то затормозило или ускорило процесс? Если да - добро пожаловать под кат!

Вам понадобится: тишина, спокойствие, и 20 минут времени. Итак:
1. Устройтесь в кресле или на диване. Можно лечь, расслабиться и закрыть глаза.
2. Представьте задачу и срок выполнения.
3. Набросайте небольшой план реализации, 3-4 пункта.
4. Теперь, что обозначенный срок вышел и задача выполнена. Вы радуетесь, коллеги жмут руку, а начальник выписывает премию :)
5. Далее, вы рассказываете более опытному коллеге о том, как вы делали эту задачу. Вспоминайте максимально подробно. Коллега будет задавать уточняющие вопросы и спрашивать нюансы.
6. Во время рассказа и свершится магия. Начнет всплывать все незапланированное.
Приведу пример.
Задача: реализовать перенос значений JSON в базу данных (БД). Срок – неделя.
1. Садимся, расслабляемся и представляем.
2. Есть задача, есть срок. Это будет отдельный сервис, принимающий JSON.
3. Примерный план: пишем сервис, содержащий веб-сервер с эндпоинтом, авторизацией и валидацией JSON. Ему понадобится библиотека для коннекта к БД.
4. Прошла неделя. Сервис готов и все довольны. Ура!
5. Пятничный вечер. Сидим в баре и рассказываем коллеге:
a. В понедельник начал писать сервис с авторизацией.
b. Во вторник сделал адаптер к БД.
c. В среду начал нагрузочное тестирование. Потребовалось делать кастомный десериализатор (des) JSON для скорости. Плюсом узнал, что кол-во коннектов к БД ограничено. Нужен пул соединений.
d. В четверг оптимизировал код. Делал des и пул соединений.
e. В пятницу поставил задачу на девопсов на деплой. Но, один девопс в отпуске, а у другого завал. В итоге, писал деплой сам. Но успел.
В ходе ретро мы выяснили, что задачу на деплой стоило ставить в понедельник. И сразу реализовывать быстрый des и пул коннектов к БД.
Чтобы данный подход заработал, потренируйтесь на нескольких реальных задачах.

С вами был Иван Дьяченко. Успехов!

Свежий взгляд на HighLoad

Видео-версия статьи: https://youtu.be/3CIxRvpBIbk
https://rutube.ru/video/ed808e41cd3b95f2132a4a2df3fab90d/

Текстовая версия статьи: https://vc.ru/services/697479-svezhiy-vzglyad-na-highload

Инвестиции в ИТ: почему экономия может обернуться убытками

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

1. Качество кода: Если в процессе разработки не уделяется должного внимания качеству кода и его архитектуре, то в будущем возникнут проблемы, которые потребуют времени и ресурсов для исправления. Код, написанный с плохими практиками, может быть трудным для понимания и модификации другими разработчиками, что затруднит сопровождение продукта.

2. Недостаточное тестирование: Отсутствие должного тестирования и контроля качества в процессе разработки может привести к появлению ошибок и непредвиденному поведению продукта. Решение таких проблем может требовать значительного времени и усилий в процессе сопровождения.

3. Отсутствие масштабируемости: Если при разработке не учитывается потребность в масштабировании продукта в будущем, то при его росте возникнут трудности и необходимость в серьезных изменениях в архитектуре и функционале. Такие изменения могут быть сложными и затратными.

4. Недостаток документации: Недостаточное ведение документации в процессе разработки усложняет понимание кода и логики продукта другими разработчиками. Это затрудняет внесение изменений и требует дополнительного времени для изучения и разбора существующего кода.

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

Расширенная версия статьи с рекомендациями https://vc.ru/706738

Эмоциональное выгорание: личный опыт борьбы

Я выделил три направления, связанных с эмоциональным выгоранием. И приемы борьбы с ними.

Внутренний ребенок

Он любит капризничать и требовать жалости к себе.
1. Выясните, что он хочет и попробуйте с ним договориться. Он не мешает вам делать текущие дела, а вы ему даете чуть позже то, о чем он просит.
2. Задайте ему вопрос: хочешь ли ты оставить все как есть, или хочешь хотя бы попытаться изменить ситуацию к лучшему? Если в ответ вы услышите, что он не хочет оставлять все как есть, ответьте ему - вставай и делай!
Это должно сработать.

Сферы влияния

1. Очертите свою сферу влияния.
2. Научитесь управлять приоритетами. Выставляйте приоритеты по значимости для вас лично, последствиям невыполнения, а также кратко- и долгосрочности профита.

Когнитивные искажения

1. Убирайте из фокуса внимания неважное, мысленно уменьшая его образ до смешных размеров.
2. Нерешенные вопросы логически воспроизводите в голове до логического завершения.
3. Не переоценивайте масштаб негативных мыслей других людей о вас.

Развернутую статью читайте здесь

Синхронно vs. Асинхронно: выбираем подход к взаимодействию микросервисов

Синхронное

В синхронном взаимодействии клиентский микросервис ожидает ответа от вызываемого микросервиса перед продолжением своей работы.

Плюсы синхрона:

1. Простота. Проще в реализации и отладке.
2. Прозрачность. Позволяет легко отслеживать и управлять последовательностью выполнения операций.

Минусы синхрона:

1. Зависимость от доступности. Если вызываемый микросервис недоступен или работает медленно, это может привести к задержкам и блокировкам в клиентском микросервисе.
2. Узкое место. Если синхронные вызовы выполняются последовательно, это может стать узким местом производительности.

Асинхронное

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

Плюсы асинхрона:

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

Минусы асинхрона:

1. Сложность. Требует более сложной реализации, так как необходимо обрабатывать асинхронные ответы и управлять состоянием запросов.
2. Усложнение отладки. Отслеживание и отладка может быть сложнее из-за распределения запросов и ответов во времени.

Что выбрать?

Правильный выбор подхода зависит от следующих факторов:

1. Время отклика. Если требуется мгновенный отклик и задержки недопустимы, синхронное взаимодействие может быть предпочтительным.
2. Надежность. Если надежность и отказоустойчивость важны, асинхронное взаимодействие может быть предпочтительным, так как избегает блокировок и позволяет более гибко обрабатывать ошибки и отказы.
3. Производительность. Если система требует высокой производительности и параллельной обработки запросов, асинхронное взаимодействие может быть более эффективным.

Развернутая статья здесь