TL; DR: складання надлишкових, модульних; тест на наявність; уважно стежити.
Після того, як зрозумів, що спроба втиснути будь-яке пояснення може затягнутися дуже довго, тому я запишу всі зроблені нами спостереження.
Допит до передумови
Хмарна система - панацея
Навіть якщо ви хотіли б повністю перейти на хмару, з найкращим постачальником хмар, вам все одно знадобиться розробити заявку на стійкість, обґрунтування. AWS може замінити ваш VM, але ваша програма повинна бути здатна перезапуститись, якщо її залишити посеред обчислення.
Ми не хочемо використовувати хмарну систему через x / y / z
Якщо ви не надто велика організація, вам краще використовувати хмарні системи. У топ-3 хмарних системах (AWS, MSFT, Google) зайняті тисячі інженерів, які нададуть вам обіцяні угоди про обмежене обслуговування (SLA) та просте керування інформаційною панеллю. Насправді це хороша угода, щоб використовувати їх замість того, щоб витратити ні копійки на цю власну компанію.
Проблеми в обстеженні та дизайні
Визначення, кількісне визначення та постійне вимірювання доступності послуги є більшим завданням, ніж написання рішення щодо проблем із доступністю.
Визначити та оцінити "доступність" важче, ніж очікувалося
Кілька зацікавлених сторін по-різному бачать доступність, і те, що може статися, - це визначення, яке надає перевагу особі, яка має найвищі зарплатні. Іноді це правильне визначення, але часто екосистема не будується навколо вимірювання одного і того ж, тому що це ідеальне визначення дуже складно виміряти, не кажучи вже про моніторинг у режимі реального часу. Якщо у вас є визначення доступності, яке неможливо відстежувати в режимі реального часу, ви знову і знову знайдете подібний проект, що займається саморобкою, з чудовими подібностями. Дотримуйтесь чогось, що має сенс, і того, що можна легко контролювати.
Люди недооцінюють складність завжди доступної системи.
Щоб звернутися до слона в кімнаті, дозвольте сказати так: "Жодна багатокомп'ютерна система не доступна на 100%. Це може бути в майбутньому, але не за допомогою сучасних технологій". Тут, маючи на увазі сучасні технології, я маю на увазі нашу нездатність надсилати сигнали швидше, ніж швидкість світла та подібні речі. Усі інженери-комп’ютери, які варті своєї солі, знають, що розподілені обчислювальні обмеження знаходяться , і більшість з них не згадають про це на засіданнях, боячись, що вони будуть схожі на нуків. Щоб компенсувати всіх тих, хто не згадує обмеження в розподілених обчисленнях , скажу, його складні, але не завжди довіряють комп’ютерам .
Люди завищують можливості своїх інженерів
На жаль, доступність потрапляє до тієї категорії, де ви не знаєте, що хочете, але знаєте, чого не хочете. Трохи складніше, що категорія "знаю, що хоче", наприклад, інтерфейс користувача. Це вимагає трохи досвіду та читання, щоб засвоїти досвід інших та ще багато чого.
Побудова доступної системи на основі ґрунту
Переконайтеся, що ви будете євангелізувати перед кожною командою з архітектури та дизайну щодо правильного пріоритету доступності як системної вимоги.
Атрибути системи, що допомагає доступності
Наступні характеристики системи показали, що сприяли доступності системи:
Надмірність
Деякі приклади цього - ніколи не мати лише одного VM позаду VIP або ніколи не зберігати лише одну копію ваших даних. Це питання, які хороший ІААС полегшить вам рішення, але вам все одно доведеться приймати ці рішення.
Модульність
Модульний REST краще, ніж монолітний SOA. Навіть модульна мікросервіс фактично доступніший, ніж звичайний HATEOS REST . Міркування можна знайти в обговоренні виходу в наступному розділі. Якщо ви займаєтеся пакетною обробкою, тоді краще проводити пакетну обробку в розумній партії 10 секунд порівняно з розправою з партією 1 000 000.
Стійкість
"I am always angry"
- Hulk
Еластична система завжди готова до відновлення. Ця стійкість застосовується до таких випадків, як підтвердження ACK для запису лише після запису на диск RAID, і, можливо, для принаймні двох центрів обробки даних. Іншим останнім трендом є використання безконфліктних структур даних , де структура даних бере на себе відповідальність за вирішення конфліктів, якщо вони представлені у двох різних версіях. Система не може бути стійкою як задумка, її потрібно передбачити і вбудувати. Провал гарантується в довгостроковій перспективі, тому ми повинні бути завжди готові до плану відновлення.
Шлях колоди
Це технічно підтип Resilience, але дуже особливий, тому що він охоплює всі можливості. Незважаючи на докладені зусилля, ми, можливо, не зможемо передбачити схему недоступності. Якщо можливо, підтримуйте достатню кількість протоколів журналу системних дій, щоб мати можливість відтворювати системні події. Це, за великої ручної вартості, дозволить вам оговтатися від непередбачених ситуацій.
Атрибути доступності
Невичерпний список атрибутів "розумності": "Для обговорення, припустимо, що запитує користувач питання:" Скільки предметів у мене в кошику для покупок? "
Правильність
Ви мусите дати максимально точну можливу відповідь, чи все в порядку помилки? Тільки для довідки, коли ви знімаєте гроші з банкомату, це не гарантовано є правильним. Якщо банк виявить, що він помилився, можливо, ви зможете скасувати транзакції. Якщо ваша система виробляє прості номери, то я б здогадався, ви можете постійно відповідати правильними відповідями.
Вихід
Пропустіть цю точку, якщо ви відповідали завжди правильно за попереднє питання теми. Іноді відповіді на питання не повинні бути точними, наприклад, скільки у мене зараз друзів у Facebook? Але відповідь, як очікується, буде весь час +/- 1. Коли ви даєте очікуваний результат, ваш урожай 100.
Послідовність
Ваша відповідь може бути правильною в один момент часу, але до того моменту, коли світло вийшов з екрана і ввійшов у сітківку спостерігача, все могло змінитися. Це робить вашу відповідь неправильною? Ні, це просто робить непослідовним. Більшість застосунків є можливими послідовними, але хитрість полягає у визначенні, яку модель узгодженості надає ваша програма. Випадково ваша програма може працювати на одному комп’ютері, ви можете пропустити це чудове читання за теоремою CAP .
Вартість
Багато що залежить від загального впливу короткострокових ефектів (втрата доходу) та довгострокових ефектів (погана репутація, утримання клієнтів). Залежно від типу клієнта (платний / безкоштовний, повторний / унікальний, власний) та доступність ресурсів повинні бути складені різні рівні гарантій доступності.
На шляху до покращення доступності існуючої системи
Оперативне управління окремими машинами та мережею настільки складне, що я припускаю, що ви залишили це хмарному провайдеру або ви вже достатньо досвідчені, щоб знати, що ви робите. Я торкнуся інших тем за доступністю. Для довгострокової стратегії « Визнач-міри-аналізуй-контроль» - це небесна відповідність, те, що я бачив сам.
- Визначте, що таке "доступність" для ваших зацікавлених сторін
- Як ви будете вимірювати те, що ви визначили
- Аналіз кореневих причин для виявлення вузьких місць
- Завдання на вдосконалення
- Постійний моніторинг ( контроль ) системи
Причини недоступності
Оскільки ми погодилися, що оперативне управління, яке охоплюватиме будь-яке управління фізичною інфраструктурою, повинно здійснюватися професіоналами, я торкнуся інших причин недоступності заради повноти. Доступність IMO також повинна включати відсутність очікуваної поведінки, тобто якщо користувачеві не показано очікуваного досвіду, то щось недоступне. Зважаючи на таке широке визначення, наступне може спричинити недоступність: - помилки в коді - випадки безпеки - проблеми з продуктивністю