`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Леонід Бараш

Надійність SaaS під питанням

+22
голоса

Зміни технології та у способах її реалізації ведуть до змін бізнес-ризиків.

Хоча хмарні послуги загалом вважаються більш надійними, компанії стикаються з новими ризиками з SaaS і загальнодоступною хмарою – ризиками, які незнайомі або не зовсім зрозумілі. Люди дивуються, коли вони стають свідками подій тривалого відключення, як-от недавня проблема з Atlassian. Раптом проблеми надійності SaaS стають актуальними, оскільки бізнес не може отримати доступ до свого улюбленого інструменту.

Унікальний ризик використання SaaS полягає в тому, що користувач не має контролю над програмою чи інструментом і не може самостійно реалізувати його повторно.

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

Для забезпечення надійності SaaS треба перш за все визначити відповідальність постачальника. Довіряйте, але перевіряйте заяви постачальників щодо угод про рівень обслуговування, які підтримують операції та плани стійкості. Вимагайте, щоб постачальники SaaS поділилися своїми можливостями стійкості. Зрозумійте дизайн, архітектуру та модель розгортання цих послуг SaaS. Вони повинні бути прозорими. Які можливості стійкості розробив постачальник SaaS, щоб протистояти збоям? Постачальник повинен чітко уявляти, які сценарії збою він охоплює, а які ні.

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

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

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

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

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

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

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

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

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

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365

+22
голоса

Напечатать Отправить другу

Читайте также

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT