Kui väljalase on hirmutav, tehakse seda harva, ja kui seda tehakse harva, on iga väljalase suur ja riskantne. Automatiseerime tee commit’ist toodanguni nii, et juurutamine on igapäevane ja igal ajal tagasi pööratav.
Kui väljalase on sündmus, mille jaoks broneeritakse kalendrisse aeg ja mille järel keegi valvab, siis probleem ei ole meeskonnas. Probleem on selles, et samm on käsitsi, kordumatu ja tagasi pööramata. Kõik kolm on lahendatavad, ja lahendus ei ole rohkem ettevaatust — see on automatiseerimine.
DevOps ei ole tööriistade nimekiri ega eraldi inimene, kes „teeb juurutuse”. See on see, et sama meeskond, kes koodi kirjutab, vastutab ka selle eest, et see toodangus töötab — ja et tal on selleks torustik, monitooring ja õigused olemas. Ülejäänu on tagajärg.
Kuus valdkonda. Enamik meeskondi alustab torustikust ja avastab kahe kuu pärast, et päris võit tuli monitooringust — sest alles siis on näha, mis toodangus tegelikult toimub.
Automaattestid, turvakontroll ja kvaliteedivärav igal liitmisel. Torustik peab olema piisavalt kiire, et seda ei hakataks mööda minema — aeglane CI õpetab meeskonna seda vältima.
Keskkonnad kirjeldatud Terraformi või samaväärsega, nii et neid saab nullist üles ehitada ja üle vaadata nagu koodi. Käsitsi tehtud muudatus, mida keegi ei mäleta, on kõige levinum toodanguprobleemi põhjus.
Mõõdikud, logid ja päringujäljed vaikimisi — mitte lisatuna pärast esimest katkestust. Häire peab tulema siis, kui midagi on katki, ja mitte siis, kui kõik on korras.
Staatiline analüüs, sõltuvuste haavatavused ja taristukonfiguratsiooni kontroll jooksevad automaatselt. Saladused elavad võtmehoidlas, mitte keskkonnamuutujate failis repositooriumis.
Docker ja Kubernetes siis, kui koormus või meeskondade arv seda nõuab — ja ausalt öeldes ei nõua seda enamik projekte. Ütleme ette, kui lihtsam lahendus teeks sama töö.
Häirete marsruutimine, käitusjuhendid ja tagasipööramise plaan, mida on ka harjutatud. Varukoopia, mille taastamist pole kunagi proovitud, ei ole varukoopia.
Valime selle, mida teie meeskond oskab hooldada. Kõige elegantsem torustik on kasutu, kui selle ainus mõistja on tarnija, kellega leping lõppeb.
Mõõdikud on olemas ja neid tasub enne ja pärast võrrelda: kui kaua väljalase võtab, kui sageli seda tehakse, kui kaua läheb tõrke märkamiseni ja kui sageli väljalase midagi katki teeb.
Kui välja lastakse harva, on iga väljalase suur ja riskantne. Kui sageli, on iga muudatus väike ja tagasi pööratav.
Enamik pikki katkestusi ei ole pikad sellepärast, et parandus oli raske, vaid sellepärast, et keegi ei teadnud.
Serverit, mille seadistust keegi ei mäleta, ei saa ei taastada ega usaldada.
Haavatavus, mis leitakse auditil, on kallim kui sama haavatavus, mis leiti liitmisel.
Alustame auditist: kuidas täna välja lastakse, kui kaua see võtab, mis on käsitsi, mida monitooritakse ja mis juhtub siis, kui midagi katki läheb. Enamik meeskondi teab vastuseid, aga need ei ole kuskil kirjas — ja just see ongi probleem.
Seejärel liigume järjekorras, mis annab kõige varem tulu: esmalt korratav ehitus ja automaattestid, siis juurutamise automatiseerimine koos tagasipööramisega, siis monitooring ja häired, ja alles lõpuks konteinerid või orkestreerimine, kui neid üldse vaja on. See järjekord on tahtlik — Kubernetes enne töötavat CI-d lisab keerukust, mitte kiirust.
Juurutamisstrateegiast sõltub, kui riskantne väljalase on. Sinine-roheline ja etapiviisiline väljalase lubavad muudatuse tagasi võtta enne, kui see kõigi kasutajateni jõuab. Ja kogu töö käib teie kontodel ja teie repositooriumides — DevOps, mille juurde kuulub sõltuvus tarnijast, on iseenda vastand.
Ütleme ette, kui Kubernetes on teie koormuse jaoks üle võlli. Keerukus, mida keegi hooldada ei jõua, on omaette tõrkeallikas.
Varukoopiat, mille taastamist ei ole proovitud, me varukoopiaks ei nimeta. Harjutus käib enne üleandmist, mitte esimese intsidendi ajal.
Seadistame häired nii, et igaüks tähendab tegevust. Meeskond, kes saab kümme valehäiret päevas, lõpetab nende lugemise.
Torustik ja taristu on dokumenteeritud ja kirjeldatud koodina. Üleandmine on ligipääsu muudatus, mitte migratsiooniprojekt.
Kulu jälgitakse keskkonna ja teenuse kaupa algusest. Enamik üllatusarveid tuleb ressurssidest, mille kohta keegi ei teadnud, et need töötavad.
Asume Tallinnas, samas ajavööndis ja samas lepinguraamistikus. Andmed jäävad soovi korral täielikult EL-i.
Tüüpilise ühe teenuse ja ühe andmebaasiga rakenduse puhul kaks kuni kolm nädalat kuni esimese automaatse toodanguväljalaskeni. Keerukamad, mitme teenusega süsteemid võtavad kauem, aga esimene konveier töötab tavaliselt esimese nädala lõpuks.
Peaaegu kindlasti mitte. Enamik ettevõtteid saab paremini hakkama Docker Compose’i või hallatud konteineriteenusega. Kubernetes tasub end ära siis, kui teil on palju teenuseid ja meeskond, kes seda haldab — muidu ostate keerukuse ilma kasuta.
Jah. Töötame teie pilvekontodes või serverites ja jätame kõik teie omandisse. Kui praegune seadistus on halb, ütleme seda ja pakume üleminekuteed, aga me ei nõua migratsiooni tingimusena.
Järjekord loeb rohkem kui tööriistade valik. Esmalt korratav ehitus ja automaattestid: ilma nendeta automatiseerib kiirem juurutamine lihtsalt vigade kiiremat toodangusse jõudmist. Seejärel juurutamise automatiseerimine koos tagasipööramisega. Siis monitooring ja häired. Ja alles seejärel konteinerid või orkestreerimine, kui neid üldse vaja on.
Me alustame auditist: kuidas täna välja lastakse, kui kaua see võtab, mis on käsitsi ja mis juhtub siis, kui midagi katki läheb. Enamik meeskondi teab vastuseid, aga need ei ole kuskil kirjas — ja just see ongi probleem.
Mõõdikud, logid ja päringujäljed seadistatakse vaikimisi, mitte pärast esimest katkestust. Päringujälg peab olema jälgitav läbi kõigi teenuste, nii et vea allikas on leitav ka siis, kui sümptom ilmneb hoopis mujal.
Häirete seadistamisel on kõige olulisem see, et igaüks tähendaks tegevust. Meeskond, kes saab kümme valehäiret päevas, lõpetab nende lugemise — ja siis ei aita ka üheteistkümnes, mis on päris. Seepärast seadistame häired sümptomi, mitte iga üksiku mõõdiku peale, ja vaatame need esimeste nädalate jooksul üle.
Kulu märgistatakse keskkonna, teenuse ja meeskonna kaupa algusest peale. Ilma märgistuseta on arve üks suur number, mille kohta keegi ei oska öelda, mis seda ajab.
Enamik üllatusi tuleb kolmest kohast: testkeskkonnad, mida keegi öösel kinni ei pane; andmeside, mida ei osatud arvestada; ja ressursid, mis jäid alles pärast katsetust, millest keegi enam ei mäleta. Seadistame eelarvehäired, mis tulevad kuu keskel, ja vaatame kasutamata ressursid regulaarselt üle. Kui koormus on ühtlane, tasub reserveeritud võimsus ära — ja me ütleme, kui see nii on.
Monitooring ja häired töötavad ööpäev läbi igal juhul — see on tehniline seadistus, mitte inimese kohalolek. Küsimus on selles, kes öösel häirele reageerib, ja see lepitakse kokku eraldi.
Oleme ausad: väike meeskond ei suuda pakkuda sama valveringi kui suur teenusepakkuja, ja me ei luba seda, mida ei suuda pidada. Enamiku süsteemide jaoks on õige vastus tööpäevane kattavus koos automaatse tagasipööramisega, mis võtab halva väljalaske ise tagasi — see katab suurema osa öistest juhtumitest ilma, et keegi peaks ärkama. Kui teie süsteem nõuab päriselt ööpäevaringset reageerimist, ütleme seda ja lepime kokku, kuidas see korraldatakse.
Kirjeldage oma olukorda paari lausega. Vastame ühe tööpäeva jooksul.