[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"guide-who-is-responsible-when-the-service-you-rent-goes-down::ru":3,"guide-related-who-is-responsible-when-the-service-you-rent-goes-down::ru":17},{"slug":4,"title":5,"excerpt":6,"body":7,"meta_title":5,"meta_description":8,"keywords":9,"category":15,"published_at":16,"updated_at":16},"who-is-responsible-when-the-service-you-rent-goes-down","Кто отвечает, когда падает арендованный сервис","Аренда сервиса не передаёт всю работу — она сдвигает черту, и обе стороны обычно считают, что другая стоит по ту сторону. Как найти эту черту для каждого сервиса, от которого вы зависите, записать её и проверить до того, как это сделает инцидент.","\u003Ch2>На какой вопрос это отвечает, а на какой нет\u003C\u002Fh2>\n\u003Cp>Вы что-то арендовали: базу данных, которую не устанавливаете, платформу, размер которой не подбираете, модель, которую вызываете, а не размещаете. Счёт приходит ежемесячно, и всё работает. А потом одним утром не работает, и первые пятнадцать минут уходят на вопрос, который никто не записал заранее: это чинить нам или им, и как мы это поймём?\u003C\u002Fp>\n\u003Cp>Это не текст о том, как внешний интерфейс со временем меняет форму: этот довод подробно разобран в материале о зависимости от API, который вам не принадлежит, и он про вывод из обращения, версии и терпимое чтение ответов. Это и не текст о том, что поставщик делает с вашими данными, — им занят материал о том, что проверить, прежде чем доверять инструменту свои данные. И это не выбор между собственным размещением и арендой, который взвешивает сравнение самостоятельного хостинга с облачными инструментами. Здесь предполагается, что решение принято и счёт оплачивается, и задаётся более скучный следующий вопрос: из работы, которая всё ещё существует, какая половина ваша?\u003C\u002Fp>\n\u003Ch2>Черта смещается по сервисам, а не по поставщикам\u003C\u002Fh2>\n\u003Cp>Обычная ошибка — составить одно мнение о поставщике и применять его повсюду. Но граница есть свойство каждого отдельного сервиса и уезжает по мере того, как сервис становится управляемым. Арендовали голую машину — операционную систему поддерживать вам. Арендовали управляемый аналог — уже нет. Арендовали готовое приложение — вам остаются учётные записи, права, конфигурация и содержимое, и это выглядит сущей мелочью ровно до дня, когда причиной инцидента становится одно из этих четырёх.\u003C\u002Fp>\n\u003Cp>Поэтому делайте это по сервисам, а не по поставщикам, и только для тех немногих, отсутствие которых вы действительно заметите. Пять-шесть записей обычно и есть вся работа, и на неё уходит один вечер.\u003C\u002Fp>\n\u003Ch2>Пять строк, которые стоит написать по каждому\u003C\u002Fh2>\n\u003Cp>Кто ставит обновления и по чьему расписанию. Кто делает резервные копии и, отдельно, кто хоть раз что-нибудь из них восстанавливал. Кто держит ключи, защищающие данные, и что станет с вашим доступом, если ключ сменят или потеряют. Кто пересматривает список людей и систем, которые до сервиса дотягиваются. И кто должен заметить проблему первым: вы своим наблюдением или они своим.\u003C\u002Fp>\n\u003Cp>Последняя строка чаще прочих остаётся пустой, и именно она решает, как начнётся плохое утро. Если честный ответ в том, что вы узнаёте от клиента, это находка, а не провал: просто наблюдение, которое вы считали чужим, оказалось ничьим.\u003C\u002Fp>\n\u003Ch2>Читайте, что обещание исключает\u003C\u002Fh2>\n\u003Cp>Обязательства по доступности обычно записаны как заголовочная цифра в окружении оговорок, и содержательная часть — оговорки. Плановое обслуживание очень часто выведено за скобки: поставщик может быть для вас недоступен совершенно законно, а заголовок при этом не шелохнётся. Ухудшение работы может не считаться недоступностью, пока не перейдена оговорённая черта. Проблемы, вызванные вашей собственной конфигурацией, исключены, а определение вашей собственной конфигурации бывает шире, чем вы ожидаете.\u003C\u002Fp>\n\u003Cp>Затем посмотрите, в чём состоит возмещение. В большинстве договоров это зачёт против будущих трат, посчитанный как доля уплаченного и затребованный вами в срок, который начинается вместе с инцидентом. Знать это стоит не потому, что важны деньги, — они редко важны, — а потому, что это говорит, чем обязательство является на самом деле. Обещание, возмещение по которому есть частичный зачёт, — это заявление о намерении с ценником, а не гарантия того, что вы будете обслуживать клиентов.\u003C\u002Fp>\n\u003Ch2>Выясните, что вы можете сделать в три часа ночи\u003C\u002Fh2>\n\u003Cp>Самый полезный вопрос об арендованном сервисе — не кто виноват, а что вы можете делать, пока он сломан. Есть ли что попробовать или есть только кому позвонить? Если только позвонить, то суть покупки — качество этого звонка: часы, в которые на него отвечают; маршрут к живому человеку, который может что-то изменить, а не только что-то записать; и входит ли этот маршрут в ваш тариф вообще или в нём есть только обещание ответить в течение суток.\u003C\u002Fp>\n\u003Cp>В ту же проверку входят ещё две вещи. Видите ли вы достаточно, чтобы диагностировать свою половину, — журналы, трассировки запросов, детали ошибок, — или единственный вид на случившееся есть только у поставщика? И есть ли источник состояния, за которым можно следить и историю которого можно читать, чтобы не решать вопрос мы это или они обновлением страницы и догадками.\u003C\u002Fp>\n\u003Ch2>Следите за днём, когда черта сдвинется\u003C\u002Fh2>\n\u003Cp>Границы смещаются тихо, в ходе обычной работы. Переезд с того, что эксплуатируете вы, на управляемый аналог передаёт полстраницы ответственности поставщику, и документ о том, кто что делает, при этом никто не открывает. Перенос компонента в схему, где софт поставщика работает внутри вашего аккаунта, возвращает ответственность назад — и часто команде, которой не сказали, что она теперь несёт ёмкость, обновления и первые десять минут каждого инцидента. Добавление нового поставщика под существующий договор наследует допущения, которые для него никто не проверял.\u003C\u002Fp>\n\u003Cp>Практическая защита — дата пересмотра. Поставьте её в документе, держите документ на одной странице и проверяйте всякий раз, когда сервис меняет тариф, переезжает в другой аккаунт или обзаводится зависимостью, которой у него раньше не было.\u003C\u002Fp>\n\u003Ch2>Как выглядит хороший результат\u003C\u002Fh2>\n\u003Cp>Одна страница на команду со списком значимых сервисов, с названным владельцем рядом с каждой строкой мы и ссылкой на пункт договора рядом с каждой строкой они. В ней нет ничего остроумного. Вся её ценность в том, что спор о том, чья это проблема, состоялся в спокойный вторник и на бумаге, а не в начале аварии, когда ответ нужен за минуты, а те, кто его знает, спят.\u003C\u002Fp>\n\u003Ch2>Тот же вопрос действует и внутри компании\u003C\u002Fh2>\n\u003Cp>Всё сказанное выше работает без изменений между двумя командами одной компании. Одна команда эксплуатирует платформу, другая на ней строит, и граница между ними ровно так же не описана, как граница с внешним поставщиком, — а зачастую и хуже, потому что договора никто не писал и все рассчитывают, что добрая воля закроет зазор. У внутренней версии есть характерный отказ: команда платформы считает, что потребитель наблюдает за своим использованием, потребитель считает, что команда платформы наблюдает за платформой, а ломается стык между ними, за которым не наблюдает никто.\u003C\u002Fp>\n\u003Cp>Лекарство — та же страница с теми же пятью строками. Она стоит часа и убирает самый утомительный разговор в эксплуатации: тот, в котором две толковые команды ждут, кто начнёт первым.\u003C\u002Fp>","Найдите эксплуатационную границу для каждого арендованного сервиса: кто обновляет, кто восстанавливает, кто замечает первым и что исключает обещание.",[10,11,12,13,14],"разделённая ответственность","эксплуатация облака","работа с поставщиками","надёжность сервиса","реакция на инциденты","deployment","2026-09-10T03:30:02+00:00",[18,23,27,31,36,41],{"slug":19,"title":20,"excerpt":21,"updated_at":22},"ai-tool-pricing-models-seat-vs-usage-vs-credits","Модели ценообразования AI-инструментов: за место, за использование и по кредитам","Три распространённых способа тарификации AI-инструментов — за место, за использование и по кредитам — и как понять, какой из них окажется дешевле именно для того, как работает ваша команда.","2026-08-05T14:32:26+00:00",{"slug":24,"title":25,"excerpt":26,"updated_at":22},"how-ai-image-generators-differ-diffusion-vs-the-rest","Чем различаются ИИ-генераторы изображений: диффузия и всё остальное, простыми словами","Нетехническое объяснение того, как работают ИИ-генераторы изображений, почему диффузионный подход стал доминирующим и каких практических различий стоит ждать от разных инструментов.",{"slug":28,"title":29,"excerpt":30,"updated_at":22},"how-to-automate-your-workflow-without-code","Как автоматизировать процесс без кода","Практическая последовательность для автоматизаций, которые выживают: выбрать подходящий процесс, описать его до того, как открывать инструмент, и предусмотреть сбои, ломающие большинство первых попыток.",{"slug":32,"title":33,"excerpt":34,"updated_at":35},"how-to-build-a-chatbot-without-coding","Как собрать чат-бота без программирования","Практический путь к работающему чат-боту на no-code инструментах: определить границы, подключить свой контент, обработать вопросы без ответа и понять реальную стоимость.","2026-08-05T14:32:27+00:00",{"slug":37,"title":38,"excerpt":39,"updated_at":40},"how-to-build-an-evaluation-set-that-does-not-go-stale","Как собрать оценочный набор, который не устареет","Большинство оценочных наборов собирают один раз, из того, что было легко достать, и они тихо перестают представлять работу. Как собрать набор из уже имеющихся отказов, подпитывать его из продакшена, защищать от системы, которую он измеряет, и понимать, когда он исчерпан.","2026-09-09T03:30:02+00:00",{"slug":42,"title":43,"excerpt":44,"updated_at":45},"how-to-change-a-prompt-without-breaking-production","Как менять промпт, не ломая прод","Промпты правят в текстовом поле и выкатывают за секунды — поэтому они ломают вещи тихо: ни компилятора, ни стектрейса, ни очевидного момента сбоя. Дайте им релизную дисциплину кода.","2026-08-24T03:30:02+00:00"]