Vastaa palvelusta deploymentin jälkeen

Määritä palvelu, josta käyttäjät riippuvat

Deployment tuo ohjelmiston saataville. Ylläpito pitää sen hyödyllisenä käyttäjien, riippuvuuksien, kuorman ja vaatimusten muuttuessa. Koodigeneraattori ei poista tätä jatkuvaa työtä.

Kuvitteellisen asiakasviennin käyttäjä tarvitsee muutakin kuin tavoitettavan sivun. Sallitut tietueet pitää saada oikeassa muodossa hyväksyttävässä ajassa. Palvelun pitää myös estää toisen organisaation tietojen käyttö.

Nimeä omistaja ennen julkaisua. Kirjaa työajan ulkopuolinen reagointi, jos se kuuluu palvelulupaukseen. Toimittaja voi tehdä osan työstä, mutta organisaatio tarvitsee edelleen selkeän päätös- ja viestintäreitin.

Valitse toimintaa tukevat signaalit

Service-level indicator eli SLI mittaa määriteltyä palvelun ominaisuutta. Service-level objective eli SLO asettaa sille tavoitteen tietyllä jaksolla. Valitse tavoite käyttäjätarpeen ja ylläpitokyvyn perusteella.

Googlen SRE-ohje kuvaa menetelmän ja error budgetin käytön luotettavuuspäätöksissä. Älä kopioi toisen palvelun tavoitetta tarkistamatta merkitystä. SLO-ohje, error budget -esimerkki.

Määritä viennille onnistunut sallittu pyyntö. Erota tarkoitettu esto järjestelmävirheestä. Dokumentoi rajaukset, jotta mittari ei parane vain jättämällä vaikeat pyynnöt pois.

Älä paranna näkyvyyttä lokittamalla kokonaisia vientitiedostoja. Kerää selvitykseen tarvittava vähimmäistieto ja suojaa pääsy siihen.

Valmistele häiriötilanteen toiminta

Päätä, kuka koordinoi, selvittää ja viestii. Pienessä tiimissä rooleja voi yhdistää, mutta vastuiden pitää säilyä selvinä. Kirjaa havainnot ja tehdyt toimet.

Googlen incident response -ohje korostaa koordinointia ja viestintää teknisen korjauksen rinnalla. Oikeakin korjaus voi jättää käyttäjät ilman tietoa tai useat tekijät muuttamaan järjestelmää ristiriitaisesti. Häiriötoiminnan ohje.

Agentti voi tiivistää lokeja ja vertailla hypoteeseja hyväksyttyjen tietorajojen sisällä. Kiire ei anna sille rajoittamattomia tuotantovaltuuksia. Käytä poikkeavaan pääsyyn määriteltyä eskalointireittiä.

Harjoittele palautumista ja rahoita ylläpito

Testaa palautusmenettely edustavalla kuvitteellisella datalla. Tunnista asiat, joita koodin rollback ei peru, kuten poistetut tietueet tai lähetetyt viestit. Kirjaa palautukseen tarvittava aika ja tieto.

Nimeä jatkuvat työt: riippuvuuspäivitykset, oikeustarkastukset, tarvittavat sertifikaattiuusinnat, kapasiteettimuutokset ja dokumentaation korjaukset. Ilman ylläpitokapasiteettia palvelun vastuut kertyvät julkaisubudjetin päätyttyä.

Valitse häiriön jälkeen havaittuja syitä korjaavat parannukset. Yhdistä ne toteutukseen ja tarkistuksiin. Näin elinkaari sulkeutuu: ylläpidon näyttö muuttaa seuraavaa määrittelyä ja toteutusta.