Разработка в Azure — это проектирование и эксплуатация целостной нагрузки, а не составление длинного перечня облачных служб. Полезная платформа связывает приложение, данные, учётные записи, сети, интеграции, выпуск изменений, диагностические данные, защиту, поддержку и восстановление с конкретным результатом для бизнеса. Гибкость облака приносит пользу лишь тогда, когда команда может безопасно менять систему, понимает её поведение и контролирует последствия роста спроса и отказов.
Начинайте с нагрузки: кода, ресурсов, данных, моделей, внешних поставщиков и порядка работы, которые вместе обеспечивают один результат. Опишите критические пути, пользователей и специалистов по эксплуатации, чувствительность информации, цепочку зависимостей, характер спроса, рынки, обязательства и срок ответственности за систему. Определите цели доступности, восстановления, быстродействия, безопасности и стоимости на языке бизнеса. «Высокодоступная», «масштабируемая» и «безопасная» остаются лишь намерениями, пока нет порогового значения и способа проверки.
Пять составляющих Azure Well-Architected — надёжность, безопасность, оптимизация расходов, совершенство эксплуатации и эффективность быстродействия — помогают оценивать решения, поскольку одно решение редко влияет только на одно свойство. Дополнительные копии могут повысить доступность, одновременно увеличив расходы и число процедур для команды. Более строгие сетевые ограничения усиливают изоляцию, но добавляют зависимости в развёртывание и поддержку. Фиксируйте суть компромисса, ответственного, доказательства и условие пересмотра, вместо того чтобы считать типовую архитектуру универсальным ответом.
Преобразуйте ценность для бизнеса в перечень критических потоков. Для каждого определите начальные условия, основной источник данных, ожидаемый результат, наибольшую полезную задержку, допустимую потерю данных, приемлемую длительность перерыва, пиковую нагрузку, географические требования, поведение в ограниченном режиме и последствия ошибочного или недоступного результата. Отделяйте важное для клиента от удобного для внутренней работы. Передача ведомости на выплату зарплаты, разрешение платежа, страница поиска, ночная выгрузка и обновление аналитики не должны без оснований получать одинаковую архитектуру.
Определите показатели и целевые уровни обслуживания до выбора избыточности. Измеряйте не только успешные ответы HTTP, но и завершённые изменения состояния бизнеса: принятый заказ, проведённый платёж, обработанный документ, созданный отчёт, доставленное уведомление, сверенную запись. Установите целевое время восстановления и допустимую точку потери данных для каждого набора данных и пути. Также назначьте тех, кто объявляет аварию, начинает восстановление, сообщает о состоянии и подтверждает возвращение службы к работе. Цели без полномочий и учебных восстановлений остаются материалом для презентации.
Описывайте спрос как распределение: обычный уровень, регулярные пики, рекламные кампании, окна пакетной обработки, концентрацию клиентских организаций, размер сообщений, рост данных и региональные различия. Учитывайте зависимости, чьи ограничения или задержки могут стать настоящим пределом мощности. Проверьте самое рискованное предположение на небольшой части системы, воспроизводящей условия эксплуатации, и реалистичном профиле нагрузки. Итогом должен стать паспорт нагрузки, а не список облачных покупок: цели, ограничения, доказательства, решения, риски, ответственные и даты пересмотра.
Базовая облачная среда определяет условия, в которых можно развёртывать и эксплуатировать нагрузки. Её масштаб зависит от размера организации, однако главные вопросы остаются неизменными: структура организаций и оплаты, группы управления и подписки, учётные записи, привилегированный доступ, устройство сети, DNS, правила, контроль безопасности, упорядочение ресурсов, названия, метки, бюджеты, журналы событий, соединения и работа самой платформы. Границу между общими ограничениями и самостоятельностью команды нагрузки нужно определить явно.
Разделите ответственность за платформу и отдельную нагрузку. Команда платформы может отвечать за общие способы управления учётными записями, соединения, правила, хранилища журналов, средства безопасности, базовые образы, модули инфраструктуры и выдачу подписок. Команда нагрузки должна отвечать за своё приложение, данные, целевые уровни обслуживания, оповещения, развёртывания, аварии, восстановление и расходы в пределах установленных правил. Для каждого общего компонента нужны ожидаемый уровень обслуживания, порядок изменений, путь передачи сложных вопросов и модель отказов, чтобы централизация не означала отсутствия ответственного.
Описывайте среды и защитные ограничения в версионируемом коде. Применяйте проверенные модули инфраструктуры, определения правил, назначения ролей, настройки диагностики, бюджеты и параметры развёртывания для создания воспроизводимых сред. Отделяйте рабочую среду от разработки и проверки настоящими границами доступа и данных: суффикс в названии не обеспечивает изоляции. Выявляйте расхождения с описанием, защищайте критические ресурсы от случайного удаления, сохраняйте историю изменений и проверяйте изменения платформы на показательных нагрузках до массового внедрения.
Выбирайте вычислительную среду в соответствии с поведением нагрузки и возможностями команды. Управляемые платформы приложений уменьшают объём обновления системного программного обеспечения и администрирования групп вычислительных узлов для HTTP-запросов и фоновой работы. Управление контейнерами оправдывает сложность, когда планирование задач, перенос между средами, изоляция или унификация платформы дают измеримую пользу. Функции подходят для событий или неравномерного спроса, если выполнение ограничено, а запуск после простоя, одновременность, предельное время и работа с состоянием понятны. Виртуальные машины остаются уместными, когда программе нужен особый контроль над операционной системой. Самый модный вариант редко оказывается самым дешёвым во владении.
Выбирайте службы данных по требованиям к согласованности, транзакциям, запросам, задержке, масштабу, хранению, восстановлению, размещению и способам доступа. Отличайте основные транзакционные данные от быстрых промежуточных копий, поисковых индексов, аналитических копий, потоков событий и архивов. Определите разделение данных, индексы, пределы соединений, резервное копирование, восстановление, переключение после отказа, шифрование, сроки хранения, удаление, изменение схемы и расходы до того, как рост сделает начальные настройки постоянными. Глобально распределённая база данных не исправляет нечёткую модель данных.
Используйте сообщения, когда временное разделение компонентов, накопление работы, рассылка нескольким получателям или устойчивая асинхронная обработка действительно нужны продукту. Определите гарантии доставки, границы упорядочения, безопасное повторное выполнение, устранение дублей, число повторных попыток, ответственного за сообщения, постоянно вызывающие сбой, обработку очереди невыполненных сообщений, повторное воспроизведение и сверку. Для синхронных вызовов установите общий предельный срок, более короткие сроки ожидания на каждом уровне, отмену, пределы одновременности, порядок прекращения вызовов после повторных сбоев и осмысленные ограниченные режимы. Распределённые системы перемещают отказ, а не устраняют его.
Оценивайте управляемые службы как решение о внешнем поставщике. Сравнивайте соответствие функций, границу безопасности, доступные регионы, ограничения, масштабирование, сетевые возможности, резервное копирование и восстановление, контроль работы, способ развёртывания, условия уровня обслуживания, состояние предварительной версии, составляющие цены, опыт команды, возможность переноса и выхода. Прежде чем утвердить архитектуру, проведите показательную проверку, охватывающую развёртывание, отказ, восстановление и измерение расходов.
Начинайте защиту с действующих лиц, ценных ресурсов, разрешённых действий, границ доверия и сценариев злоупотребления. Разделяйте учётные записи для администрирования людьми, развёртывания, работы приложения, клиентов и доступа поставщиков. Отдавайте предпочтение краткосрочным управляемым удостоверениям вместо встроенных учётных данных; сужайте роли до наименьшего практичного набора ресурсов и действий; усиленно защищайте привилегированные операции; пересматривайте доступ; предусмотрите аварийный доступ с фиксацией действий и сроком завершения.
Классифицируйте данные и проследите их путь через приложения, хранилища, резервные копии, журналы, аналитику, выгрузки, средства поддержки и внешних поставщиков. Сводите к минимуму сбор и хранение, шифруйте передачу и хранилища, определите ответственного за ключи и порядок их замены, ограничивайте открытый доступ, применяйте частные соединения там, где польза оправдывает сложность, и не допускайте чувствительных значений в адреса и диагностические данные. Для резервных копий и наборов данных вне рабочей среды нужны те же решения, что и для основного хранилища.
Сочетайте предупредительные средства, обнаружение нарушений и восстановление. Применяйте безопасные начальные настройки, обязательные правила, разделение сети, проверку прав в приложении, проверку входных данных, контроль зависимостей и образов, поиск секретных значений в коде, устранение уязвимостей, аудиторский след, обнаружение угроз и реагирование на аварии. Централизованные средства безопасности не заменяют знание конкретной нагрузки: каждое оповещение должно иметь уровень важности, контекст, ответственного, план действий и проверку работоспособности реагирования.
Сделайте защиту пригодной к изменениям. Храните версии правил и инфраструктуры, проверяйте защитные средства во время выпуска, контролируйте исключения, назначайте утверждающего их человека и срок завершения. Отрабатывайте кражу ключа, отзыв учётных данных, злонамеренный доступ, выгрузку данных, отказ поставщика и восстановление. Доказательства соблюдения требований должны возникать в результате ежедневной работы защитных средств, а не восстанавливаться наспех перед проверкой.
Надёжность начинается с модели отказов. Рассмотрите ошибки приложения, неверные настройки, перегрузку, превышение срока ожидания зависимости, накопление очереди, повреждение данных, окончание срока действия учётных данных, разрыв сети, потерю зоны доступности, нарушение работы региона, ошибку сотрудника и разрушительные действия злоумышленника. Для каждого критического потока определите способ обнаружения, сдерживание последствий, состояние клиента, влияние на данные, действие для восстановления, уполномоченного принять решение и доказательства возвращения к нормальной работе.
Применяйте избыточность там, где она обеспечивает определённое требование. Зоны доступности уменьшают риск отказа центра обработки данных, однако для этого нагрузка должна правильно распределять вычисления и данные и продолжать работу после потери зоны. Несколько регионов усложняют маршрутизацию, копирование, согласованность, развёртывание, реагирование на аварии, проверку и расходы. Выбирайте их, лишь когда последствия для бизнеса и цели восстановления оправдывают полную модель эксплуатации. Схема с двумя регионами ещё не является планом аварийного восстановления.
Для каждого удалённого вызова предусмотрите сроки ожидания, ограниченное число повторов со случайной задержкой, отмену, безопасное повторное выполнение, пределы одновременности и ограничение поступления новой работы. Накапливайте задачи в очереди, если продукт может выдержать задержку; отказывайтесь от второстепенной работы раньше, чем пострадают критические пути; сохраняйте неопределённое состояние, если результат невозможно доказать. Масштабируйте отдельные узкие места на основании данных о мощности, а не применяйте одно правило автоматического масштабирования ко всей системе. Во время проверки под нагрузкой учитывайте задержку масштабирования и ограничения службы.
Регулярно отрабатывайте восстановление. Восстановите данные в изолированной среде, проверьте их целостность и поведение приложения, воссоздайте инфраструктуру из кода, замените скомпрометированные учётные данные, имитируйте потерю зависимости, опустошите и повторно воспроизведите очереди, верните предыдущий выпуск и при необходимости выполните региональные процедуры. Сравните фактическое время восстановления и потерю данных с целями. После каждого учения и настоящей аварии обновляйте эксплуатационные инструкции, архитектуру, сведения о мощности и подготовку команды.
Путь выпуска изменений является частью платформы. Создавайте один пакет с прослеживаемым происхождением, проверяйте его и последовательно переносите между средами. Используйте инфраструктуру, описанную кодом, управляемые настройки, отдельные учётные записи нагрузки, защищённые ветви кода, проверку, согласования в соответствии с риском и разделение полномочий для чувствительных изменений. Изменения базы данных и сообщений требуют совместимой последовательности выпуска, видимого заполнения недостающих данных, способа возврата или исправления и доказательств приёмки.
Отделяйте развёртывание кода от открытия новой возможности пользователям. Применяйте переключатели возможностей или постепенное направление запросов только при наличии ответственного, безопасного исходного состояния, диагностических данных, срока удаления и условия остановки. Выбирайте постепенное обновление, параллельные среды, пробный выпуск для малой доли пользователей или волны развёртывания в соответствии с состоянием, совместимостью, мощностью и возможным масштабом последствий. Автоматизируйте обычную проверку после развёртывания и поддерживайте испытанный способ вернуть предыдущую версию или безопасно исправить текущую без нарушения целостности данных.
Контролируйте работу нагрузки от пути бизнеса до отдельного узла. Связывайте выпуски, запросы, цепочки вызовов, журналы, измерения, события, очереди, зависимости и переходы состояний с помощью идентификаторов, не раскрывающих персональные данные. Постройте модель исправности критических потоков и оповещайте о признаках, на которые команда может повлиять: уменьшении числа завершённых операций, нарушении целевых распределений задержки, росте отказов, длительном исчерпании мощности, старении очередей или расхождениях при сверке. Контролируйте объём, сроки хранения, доступ и стоимость диагностических данных.
Эксплуатация улучшается благодаря обратной связи. Пересматривайте цели обслуживания, неудачные изменения, восстановление, качество оповещений, обращения в поддержку, выводы проверок безопасности, мощность, расходы, состояние зависимостей и ручную работу. Воспринимайте эксплуатационные инструкции как знания, пригодные к выполнению; автоматизируйте повторяющиеся безопасные действия, но оставляйте человеку полномочия по неоднозначным решениям с большими последствиями. Платформа готова, когда ответственная команда способна выпускать изменения, находить причины проблем, восстанавливать работу и учиться без скрытых знаний отдельных людей.
Расходы являются свойством нагрузки. Закрепите ответственность с помощью подписок, групп ресурсов, меток, правил внутреннего распределения или показа расходов, бюджетов, прогнозов, анализа отклонений и назначенных специалистов для реагирования. Относите расходы к нагрузке, среде, клиентской организации или подразделению, если такое разделение влияет на решение. Даже нераспределённым общим службам нужны ответственный и согласованный способ распределения расходов.
Понимайте все составляющие цены каждой службы: выделенную мощность, фактическое потребление, число выполнений, передачу данных, транзакции, уровни хранения, копии, резервное копирование, сроки хранения, лицензии, поддержку и условия долгосрочных обязательств. Учитывайте среды вне эксплуатации, аварийное восстановление, средства безопасности, вычислительные узлы сборки, хранилища пакетов, журналы, период параллельной работы во время переноса, средства поставщиков и труд людей, необходимый для эксплуатации. Низкая оценка вычислений может сочетаться с дорогой сетью, диагностикой или базой данных.
Оптимизируйте на основании доказательств. Удаляйте неиспользуемые ресурсы, выключайте безопасные среды вне рабочего времени, подбирайте размер по распределению фактического потребления и запасу, улучшайте запросы и сроки хранения, выбирайте подходящие уровни хранилища, объединяйте подходящие задачи в группы, уменьшайте лишнюю передачу данных и берите долгосрочные обязательства лишь при стабильном спросе. Убедитесь, что экономия не ослабляет цели обслуживания, восстановление, безопасность или скорость выпуска. Показатели стоимости на клиента, транзакцию, документ, задачу или завершённый путь связывают архитектуру с экономикой лучше, чем один месячный итог.
Пересматривайте расходы вместе с мощностью и спросом на продукт. Прогнозируйте обычный уровень, рост, пики, отказы и перенос; установите пороги, после которых требуется архитектурное или коммерческое решение. После изменения измеряйте фактическую экономию и учитывайте труд специалистов, риск эксплуатации и стоимость выхода. Оптимизация расходов — это постоянное управление продуктом, а не разовое сокращение после неприятного счёта.
Платформа Azure успешна, когда команда может доказать, что важный для бизнеса путь остаётся безопасным, надёжным, видимым для контроля, восстанавливаемым и экономически оправданным в процессе изменений.— GARNO.TECH
Готовая к эксплуатации платформа Azure начинается с чётко определённой нагрузки и явных компромиссов. У неё есть управляемая основа, обоснованный набор служб, учётные записи с минимальными правами, защищённые данные, проверенная модель надёжности, прослеживаемый выпуск изменений, контроль критических путей и ответственность за финансы. Для этого не требуется самое большое из возможных облачных хозяйств. Нужны решения, которые можно проверять и пересматривать.
Начните с одной нагрузки, имеющей существенное значение. Зафиксируйте исходное состояние её путей, архитектуры, защитных средств, аварий, восстановления, мощности, выпуска изменений и расходов. Найдите ограничение с наибольшими последствиями для бизнеса, внедрите наименьшее достаточное улучшение, проверьте его в условиях, приближённых к эксплуатации, и измерьте результат. Расширяйте общие возможности платформы лишь тогда, когда повторяющиеся доказательства от нескольких нагрузок оправдывают это.
Опытная команда разработки в Azure должна оставить после себя больше, чем развёрнутые ресурсы. Результатом должны стать версионируемая инфраструктура, видимые решения, работоспособные средства автоматического выпуска, полезные диагностические данные, испытанное восстановление, ответственность за расходы, актуальная документация и люди, способные дальше развивать систему. Пересматривайте нагрузку по пяти составляющим Azure Well-Architected по мере изменения целей и доказательств, поскольку облачная архитектура — это постоянная практика эксплуатации, а не завершённая схема.
Опишите критические пути, данные, обязательства, действующую среду, спрос, цели обслуживания и восстановления, ответственность команды, аварии, порядок выпуска и сведения о расходах. GARNO.TECH поможет определить границы нагрузки, правила платформы, варианты архитектуры, проверку в условиях эксплуатации и поэтапный план улучшений.
Исследование и разработка решений на основе искусственного интеллекта для оптимизации бизнес-процессов и повышения эффективности принятия решений.
Анализ моделей машинного обучения для прогнозной аналитики в сфере финансов, электронной коммерции и SaaS-платформ.
Исследование технологий обработки естественного языка и компьютерного зрения для усиления автоматизации, персонализации и поддержки клиентов.
Планируйте переход в Azure по результатам бизнеса, фактам о нагрузках, правилам базовой облачной среды, защите цифровых идентичностей и данных, восстановлению, контролируемым волнам и устойчивой эксплуатации.
10 мин чтения
Оцените проект на NestJS с учётом объёма работ, неопределённости, интеграций, качества, состава команды, графика, договорной модели и полной стоимости владения.
9 мин чтения
Определите, оправдан ли переход с Express на NestJS, изучите реальное поведение системы, переносите её сквозными фрагментами, сохраняйте договоры API и правила безопасности и выпускайте изменения с проверенным возвратом к прежней версии.
10 мин чтения