Як проводити аудит інфраструктури за допомогою Well-Architected Review

Вітання аудиторії ДОУ, мене звати Ігор Шендерчук, я очолюю напрям Microsoft Azure у частині хмарної інфраструктури та DevOps в Center of Excellence (CoE) компанії SoftServe. В індустрії я понад 14 років, працював по обидва боки барикад і як розробник, і як адміністратор, нині обіймаю посаду архітектора — допомагаю впроваджувати та розбудовувати хмарні рішення для клієнтів по всьому світі. В цьому матеріалі я розповім про сервіс Well-Architected Review: навіщо він потрібен і як працює. Впевнений, що знайомство з фреймворком, на якому базується аудит, допоможе інженерам краще зрозуміти принципи побудови сучасних хмарних рішень і значно поліпшити їхню безпеку, продуктивність і надійність.

Чому взагалі варто проходити аудит

З ростом організацій змінюється та розширюється інфраструктура програмних рішень. Що більшим стає програмне рішення, то важче знайти золоту середину — баланс між потребами: безпекою, ефективністю, оптимізацією. Аудит інфраструктури допоможе знайти сильні та слабкі місця в програмному рішенні та вибудувати інфраструктуру відповідно до конкретних потреб. У цій статті ми розглянемо основні компоненти, з яких складається аудит інфраструктури, етапи його проведення, та розберемо це на прикладі.

Часто організаціям, які тільки заходять в хмари, важко зрозуміти, чи все правильно вони роблять, адже підходи та методи, що використовувались у традиційних центрах даних, більше не працюють. Проте навіть тим компаніям, які народились в хмарах, складно розібратись у всіх особливостях провайдера, тому що основний фокус у них — побудова бізнесу, а не розбудова інфраструктури в Azure, AWS чи GCP. Перед компаніями, які все ж сподіваються на власні сили та намагаються провести аудит інфраструктури власноруч, постає безліч запитань, на які вони не мають відповіді. Чи варто жертвувати ефективністю заради збереження коштів? Чи інфраструктура відповідає всім стандартам безпеки? Якщо ні, то як це виправити? Чи використовуємо ми свої ресурси максимально ефективно?

Експерти, які проводять аудит інфраструктури, володіють необхідними фреймворками (своєрідними комплексними бібліотеками), що допомагають перевірити організації відповідно до чітко заданих критеріїв.

Також усі основні хмарні провайдери мають власні Well-Architected фреймворки, з описом та інструкціями — як будувати рішення та інфраструктуру в їхній екосистемі. Зазвичай вони складаються з так званих піларів, або опорних стовпів, за різними напрямами, наприклад: безпека, надійність, оптимізація продуктивності тощо. Пілари складаються з основних принципів, роз’яснень, еталонних архітектур, шаблонів дизайну, найкращих практик і стандартів.

Усі ці компоненти забезпечують побудову якісної інфраструктури для програмного рішення у будь-якому хмарному середовищі. За допомогою цих фреймворків та аудиту інфраструктури можна визначити сильні та слабкі місця в аплікаціях та побудувати інфраструктуру відповідно до основних бажань клієнта, відштовхуючись від конкретних аспектів.

Azure Well-Architected Framework пілари і пояснення

Оскільки я краще орієнтуюся в хмарному середовищі Azure, розповім детальніше про Azure Well-Architected Framework, принципи його роботи та процес аудиту. Варто зазначити, що ці принципи та підходи до аудиту будуть релевантними і до AWS, GCP, Alibaba та інших хмарних провайдерів з урахуванням технічних особливостей кожного.

П’ять піларів Azure Well-Architected Framework

Цей фреймворк націлений на спрощення процесу аудиту та створення максимально прозорих результатів із виявленням переваг і недоліків точок інфраструктури.

Загалом пілари Azure Well-Architected Framework такі:

  • Ефективність операційних процесів (Operational Excellence) базується на моніторингу системи, тестуванні, розгортанні коду та автоматизації інфраструктури, щоб впевнитись, що вона ефективно справляється з усіма буденними операціями, використовує достатню кількість ресурсів та швидко реагує на різкі зміни зовнішнього чи внутрішнього характеру.
  • Безпека (Security) забезпечує відповідність усім протоколам захисту, конфіденційності та цілісності даних, різнорівневого доступу до аплікацій користувачами та створення контролів і тригерів, які сповіщатимуть про можливу загрозу.
  • Надійність (Reliability) визначає, чи програмне рішення виконує свою роль правильно на постійній основі. Надійне програмне рішення може легко підлаштовуватись під різні стани інфраструктури. Надійність визначає потребу резервного копіювання даних і план відновлення після помилок чи катастрофи (disaster recovery), а також тестування цілей доступності та відновлення (SLA, RTO, RPO).
  • Рівень продуктивності (Performance Efficiency) базується на ефективному використанні усіх IT та обчислювальних ресурсів. Ресурси повинні відповідати вимогам програмного рішення, інфраструктура має бути під постійним моніторингом, а рішення, які стосуються швидкості та продуктивності — бути гнучкими та сприяти розвитку цілої системи. Одна з парадигм цього пілару — це використання найкращих практик щодо масштабування, кешу та поділу баз даних на окремі незалежні частини.
  • Оптимізація витрат (Cost optimization) забезпечує визначення та ліквідацію зайвих витрат. Відповідно до аналізу історії витрат і потреб, потрібно розробити такий план інвестицій у хмарне середовище, щоб мати змогу його розширити з часом без особливого стрибка у вартості. Тут допомагають різні техніки щодо скорочення витрат, деякі з яких спрямовані на миттєвий ефект, а інші потребують більше часу та зусиль.

Процес аудиту — Azure Well-Architected Review

Використовуючи Azure Well-Architected Framework, можна не лише розробити оптимізоване програмне рішення, а й провести аналіз і знайти слабкі точки й дати рекомендації, як їх привести до належного стану. Зазвичай аналіз проводять архітектори хмарних рішень з відповідною підготовкою, знаннями та досвідом. Саме цей процес і лежить в основі аудиту інфраструктури (Azure Well-Architected Review).

Підготовка

У підготовці до аудиту насамперед варто визначитись із програмним рішенням, для інфраструктури якого ми будемо проводити аудит. Для цього ми залучаємо експертів зі сторони замовника і проводимо першу сесію, на якій розповідаємо про основні принципи Azure Well-Architected Framework, також детально про кожен пілар і про те, яким чином буде проходити аудит. Пропонуємо обговорити програмні рішення, які має клієнт, і разом вибираємо один для аудиту. Дізнаємось основні засади та вимоги щодо роботи системи: які проблеми чи сумніви вже відчуваються, чи є особливості у сфері безпеки (наприклад, стандарти PCI DSS, HIPPA, NIST, інші вимоги регуляторів), чи плануються зміни до системи найближчим часом, чи хоче клієнт зменшити витрати, збільшити продуктивність тощо.

Перевірка

Коли підготовка завершена, переходимо до процесу аудиту, де використовуємо головні п’ять піларів Azure Well-Architected Framework. В основі аудиту лежить метод технічного інтерв’ю, опитування та обговорення всіх аспектів цього фреймворку.

Microsoft безкоштовно надає доступ до інструменту оцінки Azure Well-Architected Assessment Tool, який містить 64 запитання (на момент написання статті) щодо всіх піларів. Кожне з питань містить у собі до 10 варіантів відповідей та поле для введення нотаток.

Приклад питання з Well-Architected Review Assessment tool

На кожен пілар ми плануємо до години на технічне інтерв’ю, а респондентами мають бути люди, які безпосередньо працюють з обраною системою: Product Owner, Head of Development, Technical Lead, Architect, CTO та інші. Під час технічного інтерв’ю ми проходимося по всіх питаннях інструменту, обговорюємо деталі, ставимо похідні питання та записуємо відповідну інформацію в нотатки — ці дані знадобляться для аналізу. Зазвичай під час таких сесій ми пояснюємо клієнту деталі щодо правильної побудови програмного рішення, наприклад, яким чином краще влаштувати моніторинг системи чи як краще організувати ресурси, щоб зменшити витрати. Тож ці сесії також використовуються для навчання клієнта найкращих практик, особливостей хмарного провайдера та стандартів індустрії.

Готування звіту

На цьому етапі наші архітектори проводять аналіз і готують звіт. Оскільки аудит спрямований на визначення балансу для кожного унікального програмного рішення та інфраструктури, не існує єдиного правильного підходу. Рекомендації експертів визначають як позитивні, так і негативні сторони та методи їх збалансування в середовищі. Наприклад, якщо клієнт шукає спосіб знизити витрати, то наш архітектор повинен знайти такий спосіб оптимізації витрат, аби не критично порушувати надійність чи безпеку. Якщо клієнт хоче різко підвищити продуктивність, то це може викликати значний стрибок витрат. У будь-якому разі, ціль аудиту — знайти баланс серед усіх ланок інфраструктури.

Базуючись на відповідях клієнта, на звіті, що надає Well-Architected Review tool та нашому аналізі — ми готуємо список ключових моментів, ризиків і рекомендацій. Усі рекомендації ранжуються за важливістю, від критичних до важливих.

Приклад плану звіту

Презентація звіту та подальші кроки

Звіт про аналіз інфраструктури містить технічні припущення, резюме аналізу та рекомендації. На цьому етапі нам важливо правильно подати інформацію, звернути увагу на ризики та ключові моменти, попередити замовника про всі важливі знахідки, які були виявлені під час аналізу та методи їх вирішення. Під час презентації ми пояснюємо клієнту, чому вважаємо ті чи інші моменти критичними і яким чином їх можна усунути. З рештою рекомендацій (та шляхів їх виконання) замовник може ознайомитись в матеріалах, які ми йому надсилаємо.

Звіт містить таблицю всіх рекомендації з посиланнями, як їх можна вирішити

Після презентації замовник самостійно вирішує, чи виконувати надані рекомендації, чи залишити поточний стан інфраструктури. Аби довести аудит до логічного завершення, група експертів допомагає замовнику ухвалити це рішення, пропонує шляхи перебудови інфраструктури та готується надавати консультативні та технічні послуги, аби привести систему до необхідного рівня.

Кейс-стаді

Один із наших клієнтів зі сфери логістики потребував допомоги у визначенні поточного рівня своєї інфраструктури, виявлення та виправлення загроз; але основною проблемою він вважав завеликі витрати в хмарному середовищі.

Чудова нагода для проведення Azure Well-Architected Review, тим паче цей інструмент дає змогу показати можливі рішення з оптимізації витрат з урахуванням компромісів щодо решти складових системи та в короткий термін дати результат. Архітектор спільно з експертами замовника розібрали програмне рішення та його інфраструктуру, щоб дослідити абсолютно кожен аспект відповідно до п’яти вищеперерахованих піларів. Ми провели 7 сесій із замовником, перша і остання були присвячені вибору програмного рішення для аудиту та презентації звіту, решта п’ять — піларам.

Основною вимогою клієнта було зниження витрат. Взявши це до уваги, архітектор провів аудит з акцентом на дослідження коштів, які витрачають при поточному стані інфраструктури та які клієнт би витрачав при імплементації рекомендацій експертів. Серед рекомендацій була максимальна автоматизація процесів, перегляд усіх ресурсів Azure та заміна їх на дешевші без втрати обчислювального об’єму (наприклад, заміни App Service Premium (v2) plan на новішу версію) та розділення підписки на послуги Azure для одночасного зниження витрат і зміцнення безпеки.

Завдяки розділенню та правильному використанню підписок на Production і Dev/Test, є можливість зекономити до 50% на сервісах типу Azure SQL, Virtual Machines, App Services. Також однією з важливих рекомендацій замовнику щодо безпеки та надійності було запропоновано використання Azure Application Gateway як точку входу в систему, оскільки цей сервіс інтегрований з Web Application Firewall (що захищає сервіс від поширених вебвразливостей) та має можливість автомасштабуватись в разі несподіваних чи прогнозованих навантажень.

Загалом у процесі аудиту ми виявили понад 70 елементів для покращення, 26 з яких були термінові (з точки зору ймовірних ризиків). Ми проговорили та пояснили всі критичні моменти клієнту. Окрім цього, ми запропонували нашу допомогу для реалізації покращень, на яку замовник погодився.

Висновок

Аудит програмного рішення та інфраструктури — це не лише аналіз коштів, оцінка продуктивності чи тест, який визначає рівень робочих навантажень з єдиного параметра. Це дослідження, яке дозволяє клієнтам хмарних сервісів зробити розріз всієї системи та дізнатись, які аспекти заважають або, навпаки, стимулюють розвиток їх рішення. Клієнти, які готові пройти Azure Well-Architected Review та шлях виконання рекомендацій, отримують не лише звіт з роботи своєї системи: вони значно зменшують операційні витрати, збільшують продуктивність і швидкість виходу продукту на ринок і спостерігають підвищену ефективність своїх програмних рішень і інфраструктури.

Well-Architected Review — це швидкий спосіб дізнатися, чи система відповідає поточним реаліям і хмарному середовищу, де вона розміщена, чи вона ефективна з точки зору витрат, продуктивності, надійності та безпеки. Для детального та глибокого аудиту потрібен значно глибший аналіз. Наприклад, сервіс з оптимізації витрат (Cost Optimization service) передбачає залучення кількох експертів на термін від двох до восьми тижнів залежно від розміру інфраструктури чи програмного рішення. А так званий Infrastructure Assessment може тривати від трьох тижнів до кількох місяців із залученням цілої команди архітекторів різних напрямів.

То чи Well-Architected Review є способом привести програмне рішення і інфраструктуру до золотої середини? Як мінімум, це спосіб дізнатись як ви собі зможете допомогти і розробити чіткий план досягнення надійності, безпеки, ефективності та продуктивності всієї своєї інфраструктури за відносно короткий час.

Корисні лінки

👍НравитсяПонравилось5
В избранноеВ избранном2
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Azure Well-Architected Review assessment tool;

нету ссылки

Лінк на Azure Well-Architected Review
docs.microsoft.com/en-us/assessments

У AWS WAF был ЧАПС на начальном этапе, а у Azure WAF что?
CHAPS (Cost, HA, Perfomance, Security)

В Microsoft він з’явився під назвою — Azure Architecture Framework з тими ж піларами, пізніше перейменували в Well-Architected Framework. Але в Ажурі це доволі нова річ, в порівнянні з AWS.

Подписаться на комментарии