Поемете отговорност за услугата след внедряване

Определете услугата, от която зависят потребителите

Внедряването прави софтуера достъпен. Експлоатацията го запазва полезен при промяна на потребители, зависимости, трафик и изисквания. Генератор на код не премахва тази текуща работа.

За измислен клиентски експорт потребителите се нуждаят от повече от достъпна страница. Нужни са им разрешените записи в необходимия формат за приемливо време. Услугата трябва също да предотвратява достъп до данни на друга организация.

Посочете отговорника преди пускане. Запишете кой реагира извън нормалното работно време, ако това е част от ангажимента на услугата. Доставчик може да извършва част от работата, но организацията все още се нуждае от ясен път за решения и комуникация.

Изберете сигнали, които подкрепят действия

Показател за ниво на услугата, или SLI, измерва определено свойство на поведението ѝ. Цел за ниво на услугата, или SLO, задава цел за този показател за посочен период. Изберете целта според потребителските нужди и оперативните възможности.

Указанията на Google за SRE обясняват този подход и използването на бюджет за грешки при решения за надеждност. Не копирайте целта на друга услуга, без да проверите значението ѝ. Указания за SLO, примерна политика за бюджет за грешки.

За експорта определете какво се брои за успешна допустима заявка. Разграничете очакваните откази за достъп от системните неуспехи. Документирайте изключенията, така че показателят да не може да се подобри само чрез скриване на трудни заявки.

Избягвайте да записвате пълни експорти в логове за по-добра видимост. Събирайте минималната информация, нужна за диагностика на проблема, и защитавайте достъпа до нея.

Подгответе реакцията при инцидент

Решете кой координира, кой проучва и кой комуникира. В малък екип тези роли могат да се комбинират, но отговорностите трябва да останат ясни. Пазете запис на наблюденията и действията.

Указанията на Google за реакция при инциденти наблягат на координацията и комуникацията наред с техническото ограничаване на проблема. Технически правилна поправка все пак може да остави потребителите неинформирани или няколко реагиращи да правят противоречащи си промени. Реакция при инциденти.

Агент може да обобщава логове или да сравнява хипотези в одобрени граници на данните. Не трябва да получава неограничени продукционни правомощия поради спешността на инцидента. Използвайте определен път за ескалация при извънреден достъп.

Упражнявайте възстановяването и финансирайте поддръжката

Тествайте процедурата за възстановяване с представителни измислени данни. Определете какво rollback на кода не може да отмени, включително изтрити записи или вече изпратени съобщения. Запишете времето и информацията, нужни за възстановяване на услугата.

Възложете текущата работа: обновяване на зависимости, прегледи на достъп, подновяване на сертификати, когато е приложимо, промени в капацитета и поправки на документацията. Услуга без капацитет за поддръжка натрупва задължения след изчерпване на бюджета за стартиране.

След инцидент изберете подобрения, които адресират наблюдаваните причини. Свържете ги с реализация и проверка. Това затваря жизнения цикъл: доказателствата от експлоатацията променят какво екипът специфицира и изгражда след това.