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

При цьому застосунки розроблені за традиційними методиками зазвичай включають кілька складних програмних модулів, які сильно пов’язані один з одним - через це навіть незначні зміни в коді зачіпають весь застосунок з усіма наслідками.

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

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

Взаємодіють один з одним мікросервіси через прості інтерфейси (API) і можуть бути створені з використанням різних технологічних стеків та бібліотек.

Найчастіше код для кожного мікросервісу пише одна команда розробників.

У чому різниця між монолітною та мікросервісною архітектурою?

Монолітна архітектура часто стає на заваді швидкої розробки, тестування нових функцій, внесення змін і доставлення застосунків кінцевим користувачам. Часто таку архітектуру називають «важкою» та «неповороткою»: через сильну пов’язаність і складність окремих модулів усі перелічені вище процеси вимагають більше часу та людських ресурсів. Крім цього, мікросервісна архітектура відрізняється від монолітної простотою розгортання, налагодження та додатків, є кращою з точки зору швидкості впровадження інновацій і виведення нових проєктів на ринок.

Для розгортання застосунків на основі мікросервісів використовують технологію контейнеризації. Одна з найпопулярніших платформ для запуску та управління контейнерами має назву Kubernetes.

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

Серед переваг мікросервісної архітектури слід зазначити.

Гнучкість. Зміни, що вносяться в один мікросервіс, не торкаються інших, що спрощує оновлення додатків і прискорює розробку.

Кросплатформність. Мікросервіси для однієї програми пишуть різними мовами програмування, не прив’язуючись до одного технологічного стека. Це дозволяє створювати застосунки, які однаково добре працюють у різних середовищах.

Безпека. З мікросервісною архітектурою простіше контролювати всі залежності, що виникають у процесі запуску застосунків, та керувати доступом до окремих сервісів.

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

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

За даними IDC, витрати у Європі на публічні хмари згідно з підсумками милого року склали 142 млрд, а вже до 2027-го збільшаться вдвічі — до 291 млрд дол.

Проте не все так «безхмарно»: низка організацій, зокрема державних, вбачають загрозу для хмарного суверенітету в глибокому проникненні в ЄС глобальних cloud-провайдерів. Станом на 2023-й на частку гіперскейлерів припадало 66% всього ринку хмарних обчислень.

Нестабільна геополітична обстановка вивела цифровий та хмарний суверенітет до найбільш важливих тем щодо стратегії та розвитку європейських країн. З одного боку, хмарні обчислення стали звичайним явищем для всіх сфер бізнесу, продовжує зростати потреба в технологічних інноваціях. З іншого боку, Європа зацікавлена у подальшому проникненні на ринок гіперскейлерів, але при цьому вважає важливим забезпечити цифрову безпеку своїм резидентам, зокрема державним організаціям. Проблема в тому, що «рідним домом» для трійки найбільших гіперскейлерів — це Amazon Web Services, Microsoft Azure та Google Cloud Platform — є США. І крім того, що технологічні гіганти розміщують свої обчислювальні потужності майже на всіх континентах, вони дуже сильно впливають на світову індустрію хмарних технологій.

ЄС оновив свою програму «Цифрова Європа» 2023-2024. Вона передбачає виділення 762,7 млн. євро на фінансування заходів, спрямованих на зміцнення технологічного суверенітету Європи. Наслідуючи вектор цифрової трансформації, заданий на державному рівні, багато компаній переносять свої дані у хмару, а це означає, що потреба у захисті та безпеці даних буде збільшуватися. Таким чином, Євросоюз прагне знайти оптимальну модель, в якій технології (зокрема хмарні) сприятимуть економічному зростанню, але при цьому не доведеться жертвувати цифровою безпекою та суверенітетом. Потенційну загрозу для останніх становлять північноамериканські постачальники послуг в особі гіперскейлерів.

Європейські країни роблять спроби виключити незаконну передачу даних із ЄС до США. Яскравим прикладом тому може бути кейс компанії Meta, яка саме за цим звинуваченням була оштрафована на 1,2 млрд дол. Однак перед Європою постає й інше завдання: діяти максимально акуратно - так, щоб надмірний захист не виявився контрпродуктивним. Для цього ЄС доводиться працювати одразу у двох напрямках: підтримувати партнерські відносини з гіперскейлерами, стимулюючи їх працювати в рамках європейського законодавства із захисту даних (GDPR), та одночасно стимулювати розвиток локальних хмарних сервісів. Також у Європейських країнах діють окремі закони, які частково дублюють або доповнюють GDPR. Наприклад, Bundesdatenschutzgesetz (BDSG) 2001 — закон про захист та регулювання обробки персональних даних у Німеччині.

Для забезпечення хмарного суверенітету в Європі вже зроблено певні кроки. Наприклад, деякі постачальники хмарних послуг стали партнерами, щоб запропонувати своїм клієнтам європейську альтернативу гіперскейлерам у сфері хмарних обчислень. А в Німеччині та Іспанії розміщені дві перші суверенні хмари Oracle Cloud Infrastructure (OCI), орієнтовані на клієнтів ЄС.

Відповідно до US CLOUD Act, влада та федеральні агентства США можуть отримати доступ до даних постачальників хмарних послуг, які, зокрема, зберігаються в інших країнах. Таким чином, цей закон суперечить Загальному регламенту ЄС із захисту даних (GDPR) — нагадаємо, що він застосовується абсолютно до всіх компаній незалежно від їхнього розташування, які збирають, зберігають та обробляють дані громадян ЄС. Європейська влада цілком закономірно сприймає таку ситуацію як загрозу європейському цифровому суверенітету. Щоб її знизити та одночасно забезпечити можливість здорової конкуренції для європейських хмарних продуктів на глобальному ринку, було розроблено ініціативу Gaia-X.

Ініціатива була запущена для створення в Європі хмарної інфраструктури, яка відповідає найвищим стандартам безпеки даних. Основними принципами Gaia-X є суверенітет, прозорість і безпека даних, а також створення умов для впровадження інновацій у сфері хмарних обчислень на ринку ЄС. Зараз вона поєднує інфраструктуру хмарних ресурсів, набір хмарних служб та сервісів, засоби управління та оркестрації, а також набір стандартів та протоколів для реалізації сумісності на рівні хмарних платформ та окремих сервісів. Вважається, що екосистема Gaia-X зможе забезпечити необхідний рівень розвитку та впровадження хмарних обчислень, не ставлячи під загрозу конфіденційність та безпеку персональних даних європейців.

Як бачимо, європейський та великою мірою український бізнес опинився у зоні ризику: якщо персональні дані клієнтів будуть передані до США (що можливо з урахуванням «прописки» гіперскейлерів), це буде прямим порушенням законодавства ЄС. Опинитися в такій ситуації не бажано навіть із репутаційного погляду, не кажучи вже про правові наслідки. Однак вихід є, і ми готові запропонувати його нашим клієнтам.

Як захистити дані своїх клієнтів українському бізнесу?

В Україні було розроблено власний стандарт кібербезпеки КСЗІ (Комплексна система захисту інформації), який визначає комплекс заходів та дій щодо захисту інформації. Насамперед цей стандарт регулюються трьома такими законами України: «Про інформацію», «Про захист персональних даних» та «Про захист інформації в інформаційно-телекомунікаційних системах».

19 липня 2022 року у Держспецзв’язку роз’яснили вимоги до захисту інформації в інформаційних системах у воєнний час. Зокрема, уточнили, що «для захисту інформаційних систем, у яких не опрацьовується інформація з обмеженим доступом, але захисту яких вимагає українське законодавство, може бути використана альтернативна система інформаційної безпеки відповідно до європейських стандартів ISO/IEC 27 серії». Йдеться про найвідоміший у світі стандарт для систем управління інформаційною безпекою (СУІБ) ISO/IEC 27001. Водночас як і раніше, залишається можливість отримання атестатів КСЗІ на колишніх умовах.

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

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

1. Розуміння цілей відновлення

Визначення цілей відновлення — RTO (Recovery Time Objectives) і RPO (Recovery Point Objectives) — є важливим і допомагає створити основу для кожного рішення щодо вашої стратегії резервного копіювання. Від зазначених параметрів залежить частота резервного копіювання та комплекс заходів, що необхідні для мінімізації часу простою.

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

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

2. Хмара та обсяг даних

Зберігання даних коштує дешево, але ми повинні використовувати цей інструмент з розумом.  

Ви можете класифікувати вашу інформацію за декількома наступними параметрами.

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

3. Використання хмари для відновлення

Використання хмари для відновлення має вирішальне значення, незалежно від того, чи є у вас власний центр обробки даних, чи ви покладаєтеся на сервіси на кшталт AWS. Однак не всі хмарні сервіси однакові — деякі з них можуть не підходити для потреб відновлення на рівні підприємства.

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

4. Вартість зберігання резервних копій даних

Для ефективного керування даними необхідно розуміти вартість зберігання резервних копій. Хоча зберігання даних стало більш доступним, важливо оптимізувати свій підхід. Баланс між вартістю зберігання даних і потребами у відновленні даних має вирішальне значення для забезпечення ефективних, економічно вигідних і безпечних рішень для резервного копіювання.

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

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

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

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

У чому полягають особливості хмарного резервного копіювання даних?

• Автоматизація: заплановане та максимально автоматизоване резервне копіювання.
• Масштабованість: легке збільшення або зменшення обсягу сховища за потреби.
• Шифрування даних: заходи безпеки для додаткового захисту ваших даних.
• Віддалений доступ: можливість отримувати дані з будь-якого місця, де є доступ до інтернету.
• Керування версіями: збереження декількох версій файлів для відновлення.
• Відновлення даних: швидке та легке відновлення втрачених або пошкоджених даних.
• Резервування: кілька копій даних, що зберігаються в різних місцях для додаткової надійності.
• Економічна ефективність: гнучка цінова політика та зниження витрат на обладнання.
• Крос-платформна сумісність: підтримка різних пристроїв та операційних систем.
• Відповідність вимогам: відповідність законодавчим і галузевим стандартам захисту даних.

А тепер про 6 найкращих практик хмарного резервного копіювання, які варто запровадити.

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

2. Планування резервного копіювання за розкладом
Копіювання за розкладом гарантує постійне та надійне бекапування даних через певні проміжки часу. Це мінімізує ймовірність людських помилок і гарантує, що дані будуть захищені без необхідності докладати постійні ручні зусилля.

3. Шифрування для захисту від несанкціонованого доступу
Шифрування даних — як під час передачі, так і в стані спокою — має вирішальне значення. Воно додає додатковий рівень безпеки, перетворюючи дані резервних копій у закодований формат.  Це захищає дані від несанкціонованого доступу, гарантуючи, що тільки авторизовані користувачі можуть отримати й використовувати інформацію. Так ваші конфіденційні дані будуть захищені від сторонніх очей.

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

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

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

Що ще потрібно враховувати при створенні стратегії хмарного резервного копіювання - у наступному блозі на цю тему.

Базове визначення мультихмари не відображає однієї дуже важливої деталі -— усі послуги та ресурси, які надають кілька хмарних постачальників, мають бути інтегровані в єдину екосистему. Тільки в цьому випадку можна говорити про справжній мультиклауд (multicloud) та отримання вигод з мультиклаудної стратегії.

Те, що така стратегія справді ефективна, підтверджують висновки 451 Research, що ґрунтуються на аналізі більш ніж 1500 компаній з різних регіонів. За даними аналітиків, 98% керівників IT-відділів підприємств, що брали участь в опитуванні, уже використовують мультихмарну інфраструктуру або планують це зробити.

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

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

Відсутність прив’язки до одного постачальника. Компанія страхує себе від проблеми подорожчання всіх чи кількох послуг в одного провайдера і може легко задовольняти нові потреби в додаткових хмарних продуктах.

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

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

Дотримання вимог регіональних регуляторів. Завдяки мультихмарі з’являється можливість виконувати специфічні для кожного регіону вимоги.

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

Слід зазначити, варіантів використання мультихмарного середовища велика кількість: насамперед, це резервне копіювання, підвищення мобільності робочих навантажень, оптимізація витрат, зниження ризиків та можливість надавати послуги на глобальному ринку.

Є кілька сценаріїв реалізації мультихмарної архітектури. Ось найпопулярніші з них:

• розміщення у двох різних публічних хмарах (IaaS) основних IT-сервісів та резервних копій даних відповідно;
• використання різних моделей хмар (IaaS, PaaS та SaaS) від різних постачальників послуг;
• розміщення робочих навантажень у кількох регіонах, максимально близько до розташування кінцевих користувачів IT-сервісів, щоб скоротити час доступу до них;
• розміщення даних у кількох хмарних провайдерів у різних регіонах, щоб виконати локальні вимоги до забезпечення конфіденційності даних.

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

За даними 451 Research, багато організацій використовують мультиклауд, щоб уникнути прив’язки до одного постачальника послуг та захиститися від зміни вартості. Водночас для низки компаній мультихмара сприяє підвищенню гнучкості бізнесу, спрощує впровадження інновацій і дозволяє отримувати найкращі з тих продуктів на ринку, які пропонують глобальні постачальники.

Попри позитивні тренди, впровадження мультихмарної стратегії створює деякі проблеми. Респонденти 451 Research виділили три основні:

• керування послугами різних хмарних провайдерів (34% опитаних);
• побудова мереж та міжмережевих з’єднань (30% опитаних);
• керування даними, що зберігаються у різних постачальників послуг (24% опитаних).

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

Згідно з даними Flexera, майже 82% IT-директорів заявляють, що їх найбільшою проблемою при роботі з хмарою є управління витратами на неї. Це турбує фахівців навіть більше, ніж безпека хмарних сервісів. Впровадження FinOps-практик дозволяє не лише знижувати, операційні витрати, а й ефективніше заробляти гроші завдяки хмарній трансформації.

Що ж таке FinOps?

Згідно з загальною діфініцією FinOps — це управління фінансами в хмарі (finance + operations) та є набором підходів, практик та заходів, що впроваджуються і реалізуються для оптимізації витрат на хмарну інфраструктуру.

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

Як показують опитування CloudZero, 60% компаній стверджують, що їхні витрати на хмару трохи або відчутно вищі за очікувані, при тому  80% компаній не мають точної інформації про те, хто відповідає за витрати на хмару і з чого ці витрати складаються. У 50% випадків проблеми з оцінкою цінності впровадження хмарних технологій не дозволяють досягти окупності інвестицій у хмару, за висновками PwC. Дані FinOps Foundation свідчать, що у 33% випадків бізнесу складно змусити інженерів вжити заходів щодо оптимізації витрат на хмару.

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

Але ж вернемося до FinOps, за якими базовими принципами втілюється ця концепція.
 
Перш за все - це співпраця. Впровадження підходів FinOps вимагає об’єднання різних підрозділів та команд, які повинні докладати зусиль для досягнення спільних цілей та підвищення ефективності роботи.

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

Звісно, необхідне впровадження відповідального підходу. Командам та окремим співробітникам необхідно брати відповідальність за витрати на послуги хмар, які вони використовують у своїй роботі.

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

Як і всякий важливий процес FinOps потребує централізованого керування. У компанії повинна бути команда, яка займається впровадженням необхідних практик у всіх відділах компанії, саме вона пропагує серед співробітників культуру хмарного фінансового планування.

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

Які є найпопулярніші способи скоротити хмарні витрати без шкоди для, та більш детально про FinOps-підходи, про це поговоримо наступного разу.

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

Говорити про гібридну інфраструктуру можна лише тоді, коли окремі хмарні та серверні моделі використання обчислювальних послуг взаємопов’язані та працюють у синергії. Для встановлення взаємозв’язків використовуються кілька технологій: VPN (віртуальна приватна мережа), WAN (глобальна мережа) та доступ до API (інтерфейс прикладного програмування).

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

Якщо мова йде про SLA, то головне правило: договір — не формальність! Перед підписанням вивчіть його, приділяючи особливу увагу тексту, написаному дрібним шрифтом. Зміст та процедури клієнтського сервісу, а також послуги адміністрування можуть залежати від регіону, типу передплати, тарифного плану та інших факторів. Оцініть якість укладання договору та умови SLA для вибраного провайдера. Чудово, якщо ви можете зробити більшість висновків, наведених нижче.

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

Добре якщо принципи ціноутворення дозволяють виконувати бюджетування на рік уперед (для послуг Colocation).

Перевірте, що у договорі перераховані складові послуги адміністрування: за яких умов надається підтримка апаратного забезпечення, виконується адміністрування віртуальних машин, ОС та окремих додатків. Всі рівні обслуговування мають бути чітко описані для різних продуктів, а в деяких випадках для різних локацій, типів дисків, віртуальних машин.

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

Якщо у вас є чим доповнити що до SLA, буду вдячний. А наступного разу поговоримо про таку тему, як перелік доступних послуг та служба техпідтримки.