Кто отвечает, когда падает арендованный сервис

На какой вопрос это отвечает, а на какой нет

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

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

Черта смещается по сервисам, а не по поставщикам

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

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

Пять строк, которые стоит написать по каждому

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

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

Читайте, что обещание исключает

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

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

Выясните, что вы можете сделать в три часа ночи

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

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

Следите за днём, когда черта сдвинется

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

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

Как выглядит хороший результат

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

Тот же вопрос действует и внутри компании

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

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