01

Зоны доступностиЗони доступностіAvailability zones

Одна ночь, два исхода

Одна ніч, два результати

One night, two outcomes

Облако даёт зоны. Разнести по ним систему — работа клиента, а не провайдера.

Хмара дає зони. Рознести по них систему — робота клієнта, а не провайдера.

The cloud provides the zones. Spreading the system across them is the customer’s work, not the provider’s.

Площадка остановлена целиком, сроков восстановления владелец не называет и не подтверждает, что её вообще удастся вернуть в строй. Основные сервисы самого провайдера продолжили работать. У клиентов, которые жили на этой площадке, сбои тянулись часами.

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

The site was stopped entirely; its owner named no restoration date and would not confirm that it could be brought back at all. The provider’s own core services carried on. For the customers who lived on that site, the outage dragged on for hours.

Почему так? Любое публичное облако делит ресурсы на два типа. Зональные — виртуальная машина и её диск — физически находятся в конкретном здании. Глобальные — облачная сеть, бакеты объектного хранилища — не привязаны к одной зоне, но живут внутри региона. Провайдер прямо пишет в документации: отказоустойчивость появляется, когда приложение развёрнуто сразу в нескольких зонах.

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

Why? Every public cloud divides its resources into two kinds. Zonal ones — a virtual machine and its disk — physically sit in a particular building. Global ones — the cloud network, object storage buckets — are not tied to one zone but live inside a region. The provider states it plainly in its documentation: resilience appears when the application is deployed across several zones at once.

То есть облако даёт зоны, а разнести по ним систему — работа клиента. Провайдер строил свои сервисы с расчётом на потерю площадки и потерял одну из нескольких. Клиент, у которого всё в одной зоне, потерял единственную. В момент аварии облако у обоих было одно и то же. Различались решения, принятые годом или тремя раньше.

Тобто хмара дає зони, а рознести по них систему — робота клієнта. Провайдер будував свої сервіси з розрахунком на втрату майданчика і втратив один із кількох. Клієнт, у якого все в одній зоні, втратив єдиний. У момент аварії хмара в обох була одна й та сама. Відрізнялися рішення, ухвалені роком або трьома раніше.

So the cloud provides the zones, and spreading the system across them is the customer’s work. The provider had built its services expecting to lose a site, and lost one of several. The customer with everything in one zone lost their only one. During the outage both were on the same cloud. What differed were decisions taken a year or three earlier.

Однако через 4 дня картина изменилась. Когда из строя вышла уже третья площадка, сбои начались и у тех, кто был разнесён по зонам, и у самого провайдера. Несколько зон защищают от независимых отказов: пожара в одном здании, аварии на одной подстанции. От угрозы, которая действует на все здания региона сразу, они не защищают — для неё домен отказа уже не здание, а регион и сам провайдер. Это и есть верхние уровни пирамиды, которые принято считать «концом света»: на деле они наступили за 4 дня.

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

Four days later, though, the picture changed. When a third site went down, failures began for those spread across zones too — and for the provider itself. Several zones protect against independent failures: a fire in one building, a fault at one substation. Against a threat that acts on every building in the region at once they do not — for that, the failure domain is no longer a building but a region and the provider itself. These are the upper levels of the pyramid, the ones usually treated as “the end of the world”: in practice they arrived in four days.

02

Чужое зданиеЧужа будівляSomebody else’s building

Что на самом деле арендуется

Що насправді орендується

What is actually being rented

В слове «облако» нет здания. А здание есть — с адресом, вводами питания, трассами, соседями и владельцем.

У слові «хмара» немає будівлі. А будівля є — з адресою, вводами живлення, трасами, сусідами і власником.

The word “cloud” contains no building. But a building exists — with an address, power feeds, cable routes, neighbours and an owner.

«Облако» — удобное слово: в нём нет здания. А здание есть. У него есть адрес, крыша, вводы питания, кабельные трассы, соседи и владелец.

«Хмара» — зручне слово: у ньому немає будівлі. А будівля є. У неї є адреса, дах, вводи живлення, кабельні траси, сусіди і власник.

“Cloud” is a convenient word: it contains no building. But a building exists. It has an address, a roof, power feeds, cable routes, neighbours and an owner.

Пока всё работает, разницы между «моим» и «чужим» сервером не видно. Она проявляется в тот момент, когда звучит вопрос «когда поднимемся». Если сервер ваш, на него отвечает ваша команда. Если он в чужом здании — пресс-служба партнёра. В ту ночь один из пострадавших сервисов так и написал своим пользователям: «инцидент на объекте инфраструктурного партнёра». Больше ему сказать было нечего — он знал о происходящем ровно столько же, сколько его клиенты.

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

While everything works, the difference between “my” server and “somebody else’s” is invisible. It shows up the moment the question “when will we be back up” is asked. If the server is yours, your team answers it. If it is in somebody else’s building, the partner’s press office does. That night one of the affected services wrote exactly that to its users: “an incident at an infrastructure partner’s facility”. It had nothing more to say — it knew exactly as much about what was happening as its customers did.

Если сервер ваш, на вопрос «когда поднимемся» отвечает ваша команда. Если он в чужом здании — пресс-служба партнёра.

Якщо сервер ваш, на питання «коли піднімемося» відповідає ваша команда. Якщо він у чужій будівлі — пресслужба партнера.

If the server is yours, your own team answers “when will we be back up”. If it is in somebody else’s building, the partner’s press office does.

В чужом здании вы не знаете, что стоит рядом, какие у площадки реальные вводы и на сколько часов топлива, в каком порядке после аварии будут поднимать клиентов и где в этой очереди вы. И вы не можете туда приехать.

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

In somebody else’s building you do not know what stands next to you, what the site’s real power feeds are and how many hours of fuel it holds, in what order customers will be brought back after an outage, or where you are in that queue. And you cannot drive over there.

Это не упрёк провайдерам: у хорошего провайдера всё это продумано. Однако продумано для его собственного бизнеса, а не для вашего, и в ночь аварии он в первую очередь спасает именно его. Никакой пункт договора не ускорит ответ на ваш вопрос.

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

This is not a reproach to providers: a good provider has thought all of it through. But it is thought through for their business, not yours, and on the night of an outage it is theirs they save first. No clause in a contract will speed up the answer to your question.

03

Реестр рисковРеєстр ризиківThe risk register

Перевёрнутая пирамида

Перевернута піраміда

An upside-down pyramid

Наводнение и метеорит описаны подробно. Потеря одного здания провайдера не описана вовсе.

Повінь і метеорит описані докладно. Втрата однієї будівлі провайдера не описана зовсім.

Floods and meteorites are described in detail. The loss of one of the provider’s buildings is not described at all.

В реестрах рисков нередко тщательно расписаны наводнение — в городе на высоте около 500 метров над уровнем моря, — падение метеорита и катастрофы масштаба региона. Если вода дошла до машзала на такой высоте, клиентам уже не до платежей, и вопрос доступности сервиса теряет смысл вместе с самим бизнесом.

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

Risk registers often set out a flood in meticulous detail — in a city some 500 metres above sea level — along with a meteorite strike and region-scale catastrophes. If water has reached the machine hall at that altitude, customers have other things on their minds than payments, and the question of service availability loses its meaning along with the business itself.

При этом в тех же реестрах колокейшн и облако по умолчанию считаются сверхнадёжными. Сценарий «здание провайдера перестало существовать» не рассматривается: риск передан провайдеру, у провайдера соглашение об уровне услуг, в нём много девяток. Резервную копию в другой регион того же облака при этом не делают, а про аварийное восстановление речь не заходит вовсе.

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

In the same registers, meanwhile, colocation and cloud are assumed to be ultra-reliable. The scenario “the provider’s building has ceased to exist” is not considered: the risk has been transferred to the provider, the provider has a service level agreement, and the agreement has plenty of nines in it. No backup is made to another region of the same cloud, and disaster recovery does not come up at all.

Однако сколько бы страниц ни занимало соглашение и сколько бы девяток в нём ни было, само по себе оно ничего не решает. Если ЦОД сгорел, простаивает и теряет клиентов ваш бизнес — прямо сейчас. Бизнес оператора к этому моменту уже пострадал, и ему есть чем заняться помимо ваших претензий. Получите ли вы что-то по соглашению, а через суд — неустойку, это вопрос месяцев, а то и лет. И даже тогда компенсация считается в процентах от месячной платы за услугу и никак не связана ни с вашей выручкой, ни со штрафами регулятора, ни с репутацией. То есть риск не передан: передано право когда-нибудь получить небольшую часть его стоимости.

Однак скільки б сторінок не займала угода і скільки б дев’яток у ній не було, сама по собі вона нічого не вирішує. Якщо ЦОД згорів, простоює і втрачає клієнтів ваш бізнес — прямо зараз. Бізнес оператора до цього моменту вже постраждав, і йому є чим зайнятися крім ваших претензій. Чи отримаєте ви щось за угодою, а через суд — неустойку, це питання місяців, а то й років. І навіть тоді компенсація рахується у відсотках від місячної плати за послугу і ніяк не пов’язана ні з вашою виручкою, ні зі штрафами регулятора, ні з репутацією. Тобто ризик не переданий: передане право колись отримати невелику частину його вартості.

But however many pages the agreement runs to and however many nines it contains, by itself it decides nothing. If the data centre has burned down, it is your business that is idle and losing customers — right now. The operator’s business has already suffered by then, and it has plenty to attend to besides your claims. Whether you receive anything under the agreement, or damages through the courts, is a question of months and sometimes years. And even then the compensation is calculated as a percentage of the monthly service fee and bears no relation to your revenue, the regulator’s fines or your reputation. So the risk has not been transferred: what has been transferred is the right to receive, some day, a small part of its cost.

И ещё один сценарий, которого в реестрах не встречается совсем: оператор ЦОДа мог ошибиться сам. Ошибиться в расчёте дизелей — мощности, запуска, работы под реальной нагрузкой. Ошибиться в расчёте живучести без внешнего питания — запаса топлива, подвоза, охлаждения на автономном режиме. Ошибиться в расчёте общей устойчивости площадки к катастрофическим воздействиям — пожару, повреждению конструкций, разнесению вводов и трасс. Эти расчёты принимаются на веру по сертификату, хотя сертификат подтверждает проект и построенный объект, а не поведение площадки в аварии, которую при проектировании никто не рассматривал.

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

And one more scenario that never appears in the registers at all: the data-centre operator may have got it wrong themselves. Wrong on the generators — their capacity, their starting, their behaviour under real load. Wrong on survivability without external power — the fuel reserve, resupply, cooling in island mode. Wrong on the site’s overall resilience to catastrophic events — fire, structural damage, the separation of feeds and routes. These calculations are taken on trust on the strength of a certificate, although a certificate attests to the design and the built facility, not to how the site behaves in an incident nobody considered while designing it.

Нижние уровни пирамиды закрыты техникой, верхние — расписаны в документах. Выпадает середина: ошибка в расчётах оператора, потеря одного конкретного здания и потеря доступа к нему. А это ровно тот уровень, где у организации ещё есть бизнес, клиенты и обязательства и где архитектура решает, будет простой длиться минуты или недели.

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

The lower levels of the pyramid are covered by technology and the upper ones are written up in documents. What falls out is the middle: a miscalculation by the operator, the loss of one particular building, and the loss of access to it. And that is precisely the level at which the organisation still has a business, customers and obligations, and where the architecture decides whether the outage lasts minutes or weeks.

04

Четыре модели размещенияЧотири моделі розміщенняFour hosting models

Облако, колокейшн, аренда, свой ЦОД

Хмара, колокейшн, оренда, свій ЦОД

Cloud, colocation, rental, your own data centre

Модель размещения меняет, кто чинит. Она не меняет, кто отвечает за второе здание.

Модель розміщення змінює, хто лагодить. Вона не змінює, хто відповідає за другу будівлю.

The hosting model changes who repairs things. It does not change who is responsible for a second building.

Если разложить риски по частоте и посмотреть, кто закрывает каждый уровень, картина для четырёх моделей размещения выглядит так.

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

If you sort the risks by frequency and look at who covers each level, the picture for the four hosting models comes out like this.

Публичное облако. Здание, железо, гипервизор и сеть внутри площадки — на провайдере. На вас — распределение по зонам, копии, ключи, адреса и план выхода. Парадокс в том, что второе здание в облаке ближе всего — в той же консоли, — и именно в облаке им пользуются реже всего.

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

Public cloud. The building, the hardware, the hypervisor and the network inside the site are on the provider. On you are the spread across zones, the copies, the keys, the addresses and the exit plan. The paradox is that in a cloud the second building is the closest at hand — in the same console — and in a cloud it is the least used.

Колокейшн. Здание, питание, охлаждение и охрана — на операторе. Железо, запас частей, ПО и каналы — ваши. Оборудование ваше и его можно вывезти, но доступ на площадку — по правилам оператора.

Колокейшн. Будівля, живлення, охолодження й охорона — на операторі. Залізо, запас частин, ПЗ і канали — ваші. Обладнання ваше і його можна вивезти, але доступ на майданчик — за правилами оператора.

Colocation. The building, power, cooling and security are on the operator. The hardware, the spares, the software and the links are yours. The equipment is yours and can be taken away, but access to the site is on the operator’s terms.

Аренда оборудования. Чужое железо в чужом здании. Замена неисправного — по договору арендодателя, поколение — то, что у него на складе. Лицензии, данные и архитектура — ваши. По рискам это колокейшн, где вывезти нечего.

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

Rented hardware. Somebody else’s hardware in somebody else’s building. Faulty parts are replaced under the lessor’s agreement, and the generation is whatever they have in stock. The licences, the data and the architecture are yours. In risk terms this is colocation with nothing to take away.

Собственный ЦОД. Всё ваше, включая инженерные системы и людей, которые их обслуживают. Однако одна своя площадка — тот же единый домен отказа, что и одна зона в облаке.

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

Your own data centre. Everything is yours, including the engineering systems and the people who maintain them. But a single site of your own is the same single failure domain as a single zone in a cloud.

Три уровня остаются на вас при любой модели. Первый — ошибка, неудачное изменение и шифровальщик: от них защищают копии и регламенты, а не здание. Второй и третий — потеря здания и потеря города: от них защищает только другое здание, вопрос лишь в том, как далеко оно стоит. Модель размещения решает, кто будет чинить диски и кондиционеры. Кто будет поднимать систему в другом месте — решаете вы.

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

Three levels stay with you under every model. The first is error, a bad change and ransomware: what protects against those is copies and procedures, not a building. The second and third are the loss of a building and the loss of a city: against those only another building protects, and the only question is how far away it stands. The hosting model decides who will repair disks and air conditioners. Who will bring the system up somewhere else is decided by you.

Модель размещения решает, кто будет чинить диски и кондиционеры. Кто будет поднимать систему в другом месте — решаете вы.

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

The hosting model decides who will repair disks and air conditioners. Who will bring the system up somewhere else is decided by you.

Разумная пирамида для конкретной организации строится по пяти правилам: уровни идут снизу вверх по частоте, а не по зрелищности; для каждого уровня записано, кто его закрывает, — по договору, а не по ощущению; расчёты оператора проверяются, а не принимаются на веру по сертификату; у уровней, где закрывающий — вы, есть владелец, бюджет и проверка; уровни выше потери города не планируются, а фиксируются одной строкой как принятый риск.

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

A sensible pyramid for a particular organisation is built on five rules: the levels run bottom-up by frequency rather than by drama; for each level it is written down who covers it — by contract, not by feel; the operator’s calculations are verified rather than taken on trust from a certificate; the levels you cover yourself have an owner, a budget and a test; and levels above the loss of a city are not planned for but recorded in one line as an accepted risk.

Если в реестре потеря чужого здания отмечена как «передано провайдеру», стоит открыть договор. Как правило, там будет компенсация в процентах от месячного счёта — через месяцы, а не в ту ночь, когда стоит ваш бизнес.

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

If the register records the loss of somebody else’s building as “transferred to the provider”, it is worth opening the contract. As a rule you will find compensation as a percentage of the monthly bill — months later, not on the night your business is down.

05

Инвентаризация сервисовІнвентаризація сервісівInventorying the services

Сначала — карта

Спершу — карта

The map comes first

Сервисы, связи, домены отказа, внутренний уровень обслуживания и влияние на клиента — для каждого сервиса отдельно.

Сервіси, зв’язки, домени відмови, внутрішній рівень обслуговування і вплив на клієнта — для кожного сервісу окремо.

Services, dependencies, failure domains, the internal service level and the impact on customers — for each service separately.

Всё, о чём шла речь выше, упирается в то, что обычно пропускают: инвентаризацию. Не список серверов из таблицы закупок, а карту того, что на самом деле работает и от чего зависит. Пирамиду рисков не построить для парка, который никто не может перечислить.

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

Everything discussed above runs into the thing that usually gets skipped: the inventory. Not a list of servers from a procurement spreadsheet, but a map of what actually runs and what it depends on. You cannot build a risk pyramid for an estate nobody can enumerate.

Последний столбец обычно пустует, хотя расставляет приоритеты именно он. Час простоя мобильного приложения и час простоя внутреннего портала стоят несопоставимо, а в реестре рисков они нередко записаны одной строкой «ИТ-инфраструктура». Если влияние каждого сервиса на клиента известно, видно, где вторая зона окупается за одну аварию, а где хватит копии и суток на восстановление.

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

The last column is usually empty, although it is exactly what sets the priorities. An hour of downtime for a mobile app and an hour for an internal portal cost incomparably different amounts, yet in the risk register they are often recorded in one line as “IT infrastructure”. Once the impact of each service on the customer is known, it becomes clear where a second zone pays for itself in a single outage and where a copy and a day to restore will do.

Чаще всего встречается такая картина: внутренний уровень обслуживания есть на уровне «всё 99,9%», зависимостей никто не рисовал, а домен отказа сервиса совпадает с доменом отказа самой слабой его зависимости. То есть сервис в трёх зонах, который ходит за авторизацией в одну зону, живёт в одной зоне.

Найчастіше трапляється така картина: внутрішній рівень обслуговування є на рівні «усе 99,9%», залежностей ніхто не малював, а домен відмови сервісу збігається з доменом відмови найслабшої його залежності. Тобто сервіс у трьох зонах, який ходить за авторизацією в одну зону, живе в одній зоні.

The commonest picture is this: an internal service level exists at the level of “everything is 99.9%”, nobody has drawn the dependencies, and a service’s failure domain coincides with that of its weakest dependency. So a service in three zones that fetches its authorisation from one zone lives in one zone.

Карта устаревает с каждым релизом и каждым новым подрядчиком, поэтому сверять её стоит при каждом изменении архитектуры и перед каждой учебной тревогой с переключением.

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

The map goes stale with every release and every new contractor, so it is worth reconciling at every architectural change and before every failover drill.

06

Сценарии потери площадкиСценарії втрати майданчикаScenarios for losing a site

Что может случиться со зданием

Що може статися з будівлею

What can happen to a building

Площадку можно потерять, даже если она физически цела.

Майданчик можна втратити, навіть якщо він фізично цілий.

A site can be lost even when it is physically intact.

Хрестоматийный пример из телекома. Мобильный оператор, биллинг построен на совесть. Абоненты не лежат в одной базе — они разнесены по 7 базам первого уровня, онлайн-тарификации, и 5 базам второго уровня, где живут подключения и отключения услуг и периодические списания. Расчёт голосового и интернет-трафика вынесен в отдельные слои — по 2 десятка машин на 2 десятках хостов виртуализации. У каждой физической базы своя система хранения.

Хрестоматійний приклад із телекому. Мобільний оператор, білінг побудований на совість. Абоненти не лежать в одній базі — вони рознесені по 7 базах першого рівня, онлайн-тарифікації, і 5 базах другого рівня, де живуть підключення і відключення послуг та періодичні списання. Розрахунок голосового й інтернет-трафіку винесений в окремі шари — по 2 десятки машин на 2 десятках хостів віртуалізації. У кожної фізичної бази своя система зберігання.

A textbook example from telecom. A mobile operator with a conscientiously built billing system. The subscribers do not sit in one database — they are spread across 7 first-tier databases for online rating and 5 second-tier databases holding service activations, deactivations and recurring charges. Voice and data traffic rating is carried in separate layers — a couple of dozen machines on a couple of dozen virtualisation hosts. Each physical database has its own storage system.

То есть домены отказа нарезаны так, что любая проблема с железом задевает только часть абонентов. Так и было годами: что-то у кого-то не работало, но сказать, что сервис «отвалился» для значительной части абонентов, было нельзя.

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

In other words the failure domains are carved up so that any hardware problem touches only a part of the subscriber base. And so it was for years: something was not working for somebody, but you could not say the service had “gone down” for any significant share of subscribers.

Пока в один день не пришла беда с электропитанием всего здания. Питание упало, через минуту упало ещё раз — и всё. Осталось освещение, а серверной энергии не было.

Поки одного дня не прийшла біда з електроживленням усієї будівлі. Живлення впало, за хвилину впало ще раз — і все. Залишилося освітлення, а серверній енергії не було.

Until one day trouble arrived with the power supply of the entire building. The power dropped, dropped again a minute later — and that was that. The lighting stayed on; the server room had no power.

Распределённая система, у которой все части в одном здании, поднимается не как распределённая, а как одна большая. Холодный старт десятков баз, массивов и сотен машин — это порядок запуска, проверки целостности и сверка между уровнями, и никакая распределённость его не ускоряет. Поэтапный возврат в работу до уровня около 70% занял больше 12 часов, оставшиеся 30% — ещё 2 дня. Плюс досчёт трафика задним числом.

Розподілена система, у якої всі частини в одній будівлі, піднімається не як розподілена, а як одна велика. Холодний старт десятків баз, масивів і сотень машин — це порядок запуску, перевірки цілісності і звірка між рівнями, і жодна розподіленість його не пришвидшує. Поетапне повернення в роботу до рівня близько 70% зайняло більше 12 годин, решта 30% — ще 2 дні. Плюс дорахунок трафіку заднім числом.

A distributed system with all its parts in one building comes back up not as a distributed system but as one large one. A cold start of dozens of databases, arrays and hundreds of machines means a start-up order, integrity checks and reconciliation between the tiers, and no amount of distribution speeds that up. Returning to around 70% of service took more than 12 hours in stages; the remaining 30% took another 2 days. Plus rating the traffic retroactively.

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

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

There is no design error here in the usual sense. Every level of the pyramid below the building was covered exemplarily. What was missing was the level above — a second building. All the resilience turned out to sit inside one failure domain, and on that day it was one for everybody.

Площадку можно потерять и по-другому

Майданчик можна втратити й по-іншому

A site can be lost in other ways

• Пожар и тушение. Даже локальное возгорание приводит к обесточиванию зала. Газовое пожаротушение и последующее проветривание — это часы, вода от соседних помещений — ещё хуже.
• Питание всего объекта. Уровень Tier описывает инженерную систему внутри площадки. Он ничего не говорит о том, что будет, если площадка потеряет все вводы на сутки, а топлива, договоров на подвоз и мощности дизелей окажется меньше, чем рассчитывал оператор.
• Трассы. Площадка может работать, но быть отрезанной: несколько оптических линий до столицы нередко идут по одному коридору.
• Изъятие и владелец. Зал останавливают по делу соседа; площадку продают, оператор уходит с рынка — здание стоит, свет горит, но через 90 дней нужно съехать.

• Пожежа і гасіння. Навіть локальне займання призводить до знеструмлення залу. Газове пожежогасіння і подальше провітрювання — це години, вода із сусідніх приміщень — ще гірше.
• Живлення всього об’єкта. Рівень Tier описує інженерну систему всередині майданчика. Він нічого не каже про те, що буде, якщо майданчик втратить усі вводи на добу, а палива, договорів на підвезення і потужності дизелів виявиться менше, ніж розраховував оператор.
• Траси. Майданчик може працювати, але бути відрізаним: кілька оптичних ліній до столиці нерідко йдуть одним коридором.
• Вилучення і власник. Зал зупиняють у справі сусіда; майданчик продають, оператор іде з ринку — будівля стоїть, світло горить, але через 90 днів треба з’їхати.

• Fire and firefighting. Even a local fire means the hall loses power. Gas suppression and the ventilation that follows take hours; water from neighbouring premises is worse still.
• Power to the whole facility. A Tier level describes the engineering system inside the site. It says nothing about what happens if the site loses every feed for a day and the fuel, the resupply contracts and the generator capacity turn out to be less than the operator reckoned.
• Routes. A site can be running and yet cut off: several optical lines to the capital often run through a single corridor.
• Seizure and ownership. A hall is shut down over a neighbour’s case; the site is sold, the operator leaves the market — the building stands, the lights are on, but in 90 days you have to move out.

Уровень Tier III, на который часто ссылаются в коммерческих предложениях, — хороший уровень, но это свойство одного здания. Ни Tier III, ни Tier IV не обещают, что здание переживёт потерю самого себя: устойчивость на уровне здания даёт только второе здание.

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

Tier III, so often cited in commercial proposals, is a good level — but it is a property of one building. Neither Tier III nor Tier IV promises that a building will survive the loss of itself: resilience at the building level is provided only by a second building.

07

Резервные копииРезервні копіїBackups

Копия в той же зоне

Копія в тій самій зоні

A copy in the same zone

Копию в другой регион не делают даже те, кто аккуратно копирует каждую ночь.

Копію в інший регіон не роблять навіть ті, хто акуратно копіює щоночі.

Even those who back up diligently every night do not make a copy in another region.

После аварии чаще всего звучит вопрос: «А бэкапы где?» Ответ нередко неприятный: в той же зоне.

Після аварії найчастіше звучить питання: «А бекапи де?» Відповідь нерідко неприємна: у тій самій зоні.

After an outage the commonest question is: “where are the backups?” The answer is often unpleasant: in the same zone.

Лестница защиты в облаке та же, что на своих площадках — подробно в выпуске 13 «Autosave mode=ON», — только каждая ступень включается и оплачивается отдельно, поэтому её легко пропустить. Из того, что я вижу, большинство останавливается на второй ступени. Копию в другой регион не делают даже те, кто аккуратно копирует каждую ночь.

Драбина захисту в хмарі та сама, що на своїх майданчиках — докладно у випуску 13 «Autosave mode=ON», — тільки кожен щабель вмикається й оплачується окремо, тому його легко пропустити. З того, що я бачу, більшість зупиняється на другому щаблі. Копію в інший регіон не роблять навіть ті, хто акуратно копіює щоночі.

The protection ladder in a cloud is the same as on your own sites — covered in detail in issue 13, “Autosave mode=ON” — except that each rung is enabled and billed separately, which makes it easy to skip. From what I see, most people stop at the second rung. Even those who back up diligently every night do not make a copy in another region.

А копия — ещё не аварийное восстановление. Чтобы подняться в другом месте, кроме данных нужны вычислительные ресурсы и квота на них — которую в день массовой аварии одновременно попросят все клиенты погасшей зоны; сеть, адреса и маршруты; секреты и ключи шифрования, которые не лежат в той же зоне; порядок запуска и человек, который его знает; и проверка, что всё это работает, проведённая хотя бы раз.

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

And a copy is not yet disaster recovery. To come up somewhere else you need, besides the data: compute resources and the quota for them — which on the day of a mass outage every customer of the dead zone will request at once; networking, addresses and routes; secrets and encryption keys that do not live in that same zone; a start-up order and somebody who knows it; and a test, carried out at least once, that all of this works.

Копия в другом регионе без всего остального — это восстановление за недели, а не за часы, и не то, что подразумевают, когда пишут в реестре «риск закрыт резервным копированием».

Копія в іншому регіоні без усього іншого — це відновлення за тижні, а не за години, і не те, що мають на увазі, коли пишуть у реєстрі «ризик закритий резервним копіюванням».

A copy in another region without all the rest means recovery in weeks rather than hours — and not what people mean when they write “risk covered by backup” in the register.

08

Внешние компонентыЗовнішні компонентиExternal components

Зависимости, которых нет на схеме

Залежності, яких немає на схемі

Dependencies that are not on the diagram

Страница может зависнуть на чужом скрипте, даже если ваш бэкенд работает.

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

A page can hang on somebody else’s script even when your back end is working.

В ту ночь легли и те, у кого в погасшей зоне не было ни одной своей машины.

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

That night, even those without a single machine of their own in the dead zone went down.

Современная страница или приложение собирается из десятков внешних кусков: скрипты аналитики, авторизация через внешнего провайдера, платёжные виджеты, карты, капча, библиотеки с внешних сетей доставки, DNS у внешнего оператора. Если такой кусок подгружается синхронно и без ограничения времени ожидания, страница ждёт его до бесконечности.

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

A modern page or application is assembled from dozens of external pieces: analytics scripts, sign-in through an external provider, payment widgets, maps, a captcha, libraries from external delivery networks, DNS at an external operator. If such a piece loads synchronously and without a timeout, the page waits for it indefinitely.

На схемах эти зависимости обычно не рисуют, но для пользователя разницы нет: если главная страница не открылась, не работает весь сервис. Сюда же относятся партнёры, которые сами живут в облаке: платёжный шлюз, сервис рассылок, внешний скоринг. Вы могли разнести свои системы по трём площадкам, а ваш партнёр — нет.

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

These dependencies are usually not drawn on the diagrams, but to the user it makes no difference: if the home page did not open, the whole service is down. The same applies to partners who themselves live in a cloud: the payment gateway, the messaging service, external scoring. You may have spread your systems across three sites; your partner may not have.

Отдельный урок тех дней — граница между локализацией данных и локализацией сервиса. В соседней стране сервисы провайдера работали с ошибками, и пользователям объяснили: персональные данные хранятся в стране, но распределённая инфраструктура включает компоненты в разных странах, и сбой одного из них влияет на доступность сразу в нескольких. То есть требование хранить данные локально выполнено, а домен отказа всё равно лежит в чужом здании за границей. Если вашему регулятору важна локализация, стоит спросить и о ней: где живут не только данные, но и всё, без чего сервис не работает.

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

A separate lesson from those days is the line between localising data and localising a service. In a neighbouring country the provider’s services were erroring, and users were told: personal data is stored in-country, but the distributed infrastructure includes components in several countries, and a failure of one of them affects availability in several at once. So the requirement to keep data locally was met, and the failure domain still sat in somebody else’s building abroad. If localisation matters to your regulator, it is worth asking about this too: where not only the data lives, but everything without which the service does not work.

Что с этим делать: инвентаризировать внешние вызовы на критичном пути, ставить на каждый ограничение времени ожидания и деградацию («карта не загрузилась» вместо «страница не открылась») и спрашивать ключевых партнёров, где и как они размещены, ещё при заключении договора.

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

What to do about it: inventory the external calls on the critical path, give each of them a timeout and a graceful degradation (“the map did not load” rather than “the page did not open”), and ask key partners where and how they are hosted while the contract is still being signed.

09

Аренда против покупкиОренда проти купівліRenting versus buying

Аренда «под ключ»: что остаётся на вас

Оренда «під ключ»: що залишається на вас

Turnkey rental: what stays with you

Обычно спрашивают не «надёжно ли это», а «почему это дороже, чем казалось».

Зазвичай питають не «чи надійно це», а «чому це дорожче, ніж здавалося».

The usual question is not “is this reliable” but “why is it dearer than it looked”.

Отдельная ветка того же вопроса — аренда серверов в коммерческом ЦОДе вместо покупки.

Окрема гілка того самого питання — оренда серверів у комерційному ЦОДі замість купівлі.

A separate branch of the same question is renting servers in a commercial data centre instead of buying them.

Один пример из Средней Азии. У заказчика две собственные площадки и основная мощность на гиперконвергентной платформе. На обсуждении у руководства прозвучало предложение: вместо закупки нового поколения арендовать серверы в коммерческом ЦОДе. Предложение арендодателя на первый взгляд было аккуратным: сервер с большим объёмом памяти, площадка уровня Tier III, поддержка круглосуточно. Однако при разборе заметная часть расходов в цену аренды не вошла.

Один приклад із Середньої Азії. У замовника два власні майданчики і основна потужність на гіперконвергентній платформі. На обговоренні в керівництва прозвучала пропозиція: замість закупівлі нового покоління орендувати сервери в комерційному ЦОДі. Пропозиція орендодавця на перший погляд була акуратною: сервер із великим обсягом пам’яті, майданчик рівня Tier III, підтримка цілодобово. Однак при розборі помітна частина витрат у ціну оренди не ввійшла.

One example from Central Asia. A customer with two sites of their own and most of their capacity on a hyperconverged platform. At a management discussion a proposal came up: rather than buying the new generation, rent servers in a commercial data centre. At first glance the lessor’s offer looked tidy: a server with plenty of memory, a Tier III site, round-the-clock support. On examination, though, a considerable share of the costs was not in the rental price.

Главная строка — лицензии. Модель «приносите своё»: операционную систему, платформу виртуализации и всё остальное приносит клиент. Арендуемый сервер был на предыдущем поколении и с меньшим числом ядер, поэтому на каждый свой сервер требовалось от 1,3 до 2 арендованных. Лицензии, которые считаются по физическим ядрам, растут вместе с этим числом — подробно в выпуске 08 «Строки и ядра».

Головний рядок — ліцензії. Модель «приносьте своє»: операційну систему, платформу віртуалізації і все інше приносить клієнт. Орендований сервер був на попередньому поколінні і з меншою кількістю ядер, тому на кожен свій сервер потрібно було від 1,3 до 2 орендованих. Ліцензії, які рахуються за фізичними ядрами, зростають разом із цим числом — докладно у випуску 08 «Рядки і ядра».

The main line is licences. A bring-your-own model: the operating system, the virtualisation platform and everything else come from the customer. The rented server was of the previous generation with fewer cores, so every server of their own required between 1.3 and 2 rented ones. Licences counted by physical cores grow along with that number — see issue 08, “Line items and cores”.

И главное: аренда в одном коммерческом ЦОДе ничего не меняет в пирамиде. Это по-прежнему одно здание, только чужое. Аренда не всегда хуже покупки: в выпуске 07 «Четыре контура» разобраны случаи, где она оправдана, — временная нагрузка, пилоты, вторая площадка под холодный резерв. Но сравнивать нужно полную стоимость на горизонте 3 лет, а не цену сервера в месяц.

І головне: оренда в одному комерційному ЦОДі нічого не змінює в піраміді. Це, як і раніше, одна будівля, тільки чужа. Оренда не завжди гірша за купівлю: у випуску 07 «Чотири контури» розібрані випадки, де вона виправдана, — тимчасове навантаження, пілоти, другий майданчик під холодний резерв. Але порівнювати потрібно повну вартість на горизонті 3 років, а не ціну сервера на місяць.

And above all: renting in one commercial data centre changes nothing in the pyramid. It is still one building, only somebody else’s. Renting is not always worse than buying: issue 07, “Four environments” covers the cases where it is justified — temporary load, pilots, a second site for cold standby. But what has to be compared is the full cost over three years, not the monthly price of a server.

10

Адреса, маршрут, людиАдреси, маршрут, людиAddresses, routes, people

Кто управляет переездом

Хто керує переїздом

Who runs the move

Скорость переезда определяется не железом.

Швидкість переїзду визначається не залізом.

The speed of a move is not determined by hardware.

Если площадка потеряна, всё решает, насколько быстро вы окажетесь в другом месте. Показательно, что уже на второй день провайдер договорился с несколькими другими облачными операторами об ускоренном переезде своих пострадавших клиентов. Это правильный шаг и лучший ответ на вопрос, нужна ли копия у другого провайдера. Только переезжать будут все сразу, и первым поедет тот, у кого копия уже там.

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

Once a site is lost, everything turns on how fast you can be somewhere else. Tellingly, by the second day the provider had arranged with several other cloud operators for an accelerated move of its affected customers. That is the right move and the best answer to the question of whether you need a copy at another provider. Except that everyone will be moving at once, and the first to go will be whoever already has a copy there.

• Адреса. Если публичные адреса ваших сервисов принадлежат провайдеру, переезд означает смену адресов, DNS, сертификатов и настроек у всех внешних партнёров. Собственная независимая адресация и BGP позволяют увести трафик на другую площадку, не меняя адресов.
• Маршрут. Канал до резервной площадки должен существовать до аварии, а не заказываться после неё. В день массовой аварии операторы связи перенаправляют магистральный трафик, и оставшиеся узлы перегружаются у всех одновременно.
• Ёмкость. Подняться в другой зоне по требованию в тот же час захотят все клиенты погасшей зоны.
• Люди и порядок. Кто принимает решение о переключении, в каком порядке поднимаются системы, кто проверяет результат. Если этого нет на бумаге, это будут решать ночью в мессенджере.

• Адреси. Якщо публічні адреси ваших сервісів належать провайдеру, переїзд означає зміну адрес, DNS, сертифікатів і налаштувань у всіх зовнішніх партнерів. Власна незалежна адресація і BGP дозволяють відвести трафік на інший майданчик, не змінюючи адрес.
• Маршрут. Канал до резервного майданчика має існувати до аварії, а не замовлятися після неї. У день масової аварії оператори зв’язку перенаправляють магістральний трафік, і вузли, що залишилися, перевантажуються у всіх одночасно.
• Ємність. Піднятися в іншій зоні на вимогу в ту саму годину захочуть усі клієнти погаслої зони.
• Люди і порядок. Хто ухвалює рішення про перемикання, у якому порядку піднімаються системи, хто перевіряє результат. Якщо цього немає на папері, це вирішуватимуть уночі в месенджері.

• Addresses. If your services’ public addresses belong to the provider, moving means changing addresses, DNS, certificates and settings at every external partner. Your own provider-independent addressing with BGP lets you steer traffic to another site without changing addresses at all.
• Routes. The link to the standby site has to exist before the outage, not be ordered after it. On the day of a mass outage the carriers reroute backbone traffic, and the remaining nodes become congested for everybody at once.
• Capacity. Every customer of the dead zone will want to come up in another zone on demand in that same hour.
• People and order. Who decides to fail over, in what order the systems come up, who verifies the result. If that is not on paper, it will be decided at night in a messaging app.

11

Чек-листЧек-листChecklist

Что проверить у себя

Що перевірити у себе

What to check in your own estate

Вопросы, на которые лучше ответить до аварии, а не после.

Питання, на які краще відповісти до аварії, а не після.

Questions better answered before an outage than after one.

1. Есть ли карта сервисов: связи, домены отказа, внутренний уровень обслуживания и влияние на клиента?
2. Есть ли в реестре потеря одного здания, своего и чужого, и кто закрывает каждый уровень по договору?
3. Где лежат копии: в той же зоне, в другой, в другом регионе, у другого провайдера?
4. Есть ли неудаляемая копия вне основной учётной записи и где лежат ключи?
5. Сколько часов займёт подняться в другом месте и проверялось ли это хотя бы раз?
6. Ёмкость на резервной площадке есть заранее или её ждут в день аварии?
7. Чьи публичные адреса у ваших сервисов и можно ли увести трафик, не меняя их?
8. Какие внешние скрипты и сервисы стоят на критичном пути и есть ли у них ограничения времени ожидания?
9. Что даст соглашение об уровне услуг в ночь аварии и сколько стоит ваш час простоя, пока вы ждёте компенсацию?
10. Для аренды: посчитана ли полная стоимость на 3 года — лицензии, хранилище, канал, выход?

1. Чи є карта сервісів: зв’язки, домени відмови, внутрішній рівень обслуговування і вплив на клієнта?
2. Чи є в реєстрі втрата однієї будівлі, своєї та чужої, і хто закриває кожен рівень за договором?
3. Де лежать копії: у тій самій зоні, в іншій, в іншому регіоні, в іншого провайдера?
4. Чи є копія, що не видаляється, поза основним обліковим записом і де лежать ключі?
5. Скільки годин займе піднятися в іншому місці і чи перевірялося це хоча б раз?
6. Ємність на резервному майданчику є заздалегідь чи її чекають у день аварії?
7. Чиї публічні адреси у ваших сервісів і чи можна відвести трафік, не змінюючи їх?
8. Які зовнішні скрипти і сервіси стоять на критичному шляху і чи є в них обмеження часу очікування?
9. Що дасть угода про рівень послуг у ніч аварії і скільки коштує ваша година простою, поки ви чекаєте компенсацію?
10. Для оренди: чи порахована повна вартість на 3 роки — ліцензії, сховище, канал, вихід?

1. Is there a service map: dependencies, failure domains, the internal service level and the impact on customers?
2. Does the register contain the loss of one building, yours and somebody else’s, and who covers each level by contract?
3. Where do the copies live: the same zone, another zone, another region, another provider?
4. Is there an undeletable copy outside the main account, and where are the keys?
5. How many hours would it take to come up elsewhere, and has that been tested even once?
6. Is the capacity at the standby site reserved in advance, or awaited on the day of the outage?
7. Whose public addresses do your services use, and can traffic be steered away without changing them?
8. Which external scripts and services sit on the critical path, and do they have timeouts?
9. What will the service level agreement give you on the night of the outage, and what does an hour of your downtime cost while you wait for compensation?
10. For rental: has the full three-year cost been calculated — licences, storage, links, exit?

12

ИтогПідсумокWrap-up

Вместо вывода

Замість висновку

In place of a conclusion

Ни один из клиентов, лежавших в те дни, не выбирал «пусть у нас всё ляжет». Выбирали одну зону — дешевле, копии рядом — быстрее, адреса провайдера — так было из коробки. Вместе это долг из выпуска 12 «Долг и дефолт», и в те дни его предъявили к оплате сразу десяткам организаций.

Жоден із клієнтів, які лежали тими днями, не обирав «нехай у нас усе ляже». Обирали одну зону — дешевше, копії поруч — швидше, адреси провайдера — так було з коробки. Разом це борг із випуску 12 «Борг і дефолт», і тими днями його пред’явили до оплати одразу десяткам організацій.

Not one of the customers who were down in those days chose “let everything of ours fall over”. They chose one zone because it was cheaper, copies nearby because it was faster, the provider’s addresses because that was what came out of the box. Together that is the debt from issue 12, “Debt and default”, and in those days it was called in from dozens of organisations at once.

Это не аргумент против облака и не за собственный ЦОД. Вопрос не в том, своё или чужое, и не в подробности соглашения, а в том, сколько у вас зданий и сколько часов займёт переезд: в ночь аварии стоит ваш бизнес, а компенсация придёт потом — если придёт.

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

This is not an argument against the cloud or for your own data centre. The question is not whether it is yours or somebody else’s, nor how detailed the agreement is, but how many buildings you have and how many hours the move would take: on the night of the outage it is your business that is down, and the compensation arrives later — if it arrives.

Ваш сервер — действительно ваш, если на вопросы из чек-листа вы отвечаете без звонка партнёру.

Ваш сервер — справді ваш, якщо на питання з чек-листа ви відповідаєте без дзвінка партнеру.

Your server is really yours if you can answer the checklist questions without calling your partner.