Kas yra „DevOps“? – O’Reilly radaras

Adriano Cockcrofto straipsnis apie „NoOps“ „Netflix“ įžiebė ginčą, kuris jau keletą mėnesių smilkė. Išsamus Johno Allspawo atsakymas į Adriano straipsnį yra esminis dalykas: tai, ką Adrianas apibūdino kaip „NoOps“, iš tikrųjų nėra. Operacijos niekur nedingsta. Laikui bėgant atsakomybė gali pasikeisti ir keičiasi, o keičiasi ir pareigybės aprašymai. Bet nesvarbu, kaip jūs jį supjaustote, reikia atlikti tuos pačius darbus, o vienas iš tų darbų yra operacijos. Tai, ką Adrianas vadina „NoOps“ per „Netflix“, ne tiek skiriasi nuo operacijų „Etsy“. Bet tai tik kelia klausimą: ką mes turime omenyje turėdami „operacijas“ XXI amžiuje? Jei „NoOps“ yra operacijų pakeitimo veiksmas, kuris įtartinai atrodo kaip operacijos, akivaizdu, kad kyla painiava. Dabar, kai dalis aistros aprimo, atėjo laikas geriau suprasti, ką turime omenyje operacijomis ir kaip ji pasikeitė bėgant metams.

Neseniai per pietus Jonas pastebėjo, kad dar kompiuterių amžiaus aušroje nebuvo jokio skirtumo tarp „dev“ ir „ops“. Jei vystėtės, operavote. Sumontavote juostas, apvertėte jungiklius priekiniame skydelyje, perkraunote, kai viskas sugedo, ir galbūt net pakeitėte perdegusius vakuuminius vamzdelius. Ir jūs turite dėvėti geeky baltą laboratorijos paltą. „Dev“ ir „ops“ pradėjo skirtis praėjusio amžiaus 6-ajame dešimtmetyje, kai programuotojai / analitikai į skaitytuvus išmetė perfokortų dėžutes, o „kompiuterių operatoriai“ už stiklo sienos lakstė aplink tvirtinimo juostas, reaguodami į „IBM JCL“. Operatoriai taip pat ištraukė spausdintuvus iš linijinių spausdintuvų ir įstūmė juos į etiketes su skylėmis, kur jūsų išvestis buvo paduota jūsų pavarde.

Aštuntajame dešimtmetyje atėjus minikompiuteriams, o 8-ajame dešimtmetyje asmeniniams kompiuteriams buvo sugriauta siena tarp didžiųjų kompiuterių operatorių ir vartotojų, todėl 1980-ųjų ir 90-ųjų sistemos ir tinklo administratoriai atsirado. Tai buvo šiuolaikinės „IT operacijų“ kultūros gimimas. Minikompiuterių vartotojai dažniausiai buvo kompiuterių specialistai, turintys pakankamai žinių, kad būtų pavojingi. (Prisimenu, kai naujam direktoriui buvo suteiktas šakninis slaptažodis ir liepta „susikurti sau sąskaitą“ … ir nedelsiant sudužo VAX, kurį bendrino apie 30 vartotojų). Kompiuterių vartotojams reikalingi tinklai; jiems reikėjo paramos; jiems reikėjo bendrų išteklių, tokių kaip failų serveriai ir pašto serveriai. Taip, BOFH („Niekšių operatorius iš pragaro“) yra šių dienų priminimas. Prisimenu, kaip man buvo pasakyta, kad „niekam kitam“ nekyla problemų, su kuriomis susiduriate – ir neperžengėte jos tol, kol per įmonės susirinkimą nustatėme, kad visi turi tą pačią problemą šiek tiek skirtingais būdais. Nenuostabu, kad norime, kad dingtų op. Nenuostabu, kad norėjome sienos tarp kūrėjų ir sisteminių administratorių, ypač todėl, kad teoriškai asmeninio kompiuterio ir darbalaukio darbo vietos atsiradimas reiškė, kad visi galime būti atsakingi už savo mašinas.

Tačiau kažkas turi išlaikyti veikiančią infrastruktūrą, įskaitant vis svarbesnes svetaines. Didėjant bendrovėms ir skaičiavimo įrangai, daugelio sistemos administratorių ugnies gesinimo mentalitetas nebuvo menkas. Kai visa įmonė veikia vienoje 386 dėžutėje (kaip O’Reilly 1990 m.), Neaiškių komandinės eilutės užkalbėjimų murmėjimas yra tinkamas būdas išspręsti problemas. Bet tai neveikia, kai kalbate apie šimtus ar tūkstančius mazgų „Rackspace“ ar „Amazon“. Žvelgiant iš operacijų požiūrio, didelė žiniatinklio istorija nėra evoliucija link visaverčių programų, kurios veikia naršyklėje; tai augimas nuo pavienių serverių iki dešimčių serverių iki šimtų, iki tūkstančių, iki („Google“ ar „Facebook“ atveju) milijonų. Kai naudojatės tokiu mastu, problemų sprendimas komandinėje eilutėje tiesiog nėra pasirinkimas. Negalite sau leisti leisti mašinoms išeiti iš sinchronizacijos naudojant ad-hoc pataisymus ir pleistrus. Pasakymas: „Mums reikia 125 serverių internetu, ASAP, ir nėra laiko jį automatizuoti“ (kaip susidūrė Sascha Batesas) yra nelaimės receptas.

Operacijų bendruomenės atsakas į masto problemą nestebina. Viena iš O’Reilly greičio konferencijos temų yra „Infrastruktūra kaip kodas“. Jei operacijas atliksite patikimai, turite jas padaryti atkuriamas ir programines. Taigi virtualios mašinos apsaugo programinę įrangą nuo konfigūracijos problemų. Taigi „Puppet“ ir „Chef“ automatizuoja konfigūraciją, todėl žinote, kad kiekviena mašina turi identišką programinės įrangos konfigūraciją ir teikia tinkamas paslaugas. Taigi „Vagrant“ užtikrina, kad visos jūsų virtualios mašinos nuo pat pradžių būtų sukonstruotos identiškai. Taigi automatiniai stebėjimo įrankiai, skirti užtikrinti, kad jūsų klasteriai veikia tinkamai. Nesvarbu, ar mazgai yra jūsų duomenų centre, prieglobos objekte, ar viešame debesyje. Jei nerašote programinės įrangos jiems valdyti, neišgyvenate.

Be to, tolstant vis labiau nuo tradicinių aparatūros serverių ir tinklų bei į pasaulį, kuris virtualizuojamas visais lygmenimis, senojo tipo sistemos administravimas nustoja veikti. Fizinės mašinos fizinių mašinų kambaryje neišnyks, tačiau jie nebėra vienintelis dalykas, dėl kurio sistemos administratorius turi jaudintis. Kur yra virtualaus egzemplioriaus, veikiančio tam tikroje apgyvendinimo įstaigoje, pagrindinio disko įrenginys? Kur yra tinklo prievadas virtualiame jungiklyje? Žinoma, 9-ojo dešimtmečio sistemos administratoriai valdė šiuos išteklius naudodami programinę įrangą; joks druskos vertas sysadminas neatėjo be „Perl“ scenarijų aplanko. Skirtumas tas, kad dabar patys ištekliai gali būti fiziniai, arba jie gali būti tik programinė įranga; tinklo prievadas, diskų įrenginys ar procesorius neturi nieko bendro su fiziniu objektu, į kurį galite nukreipti arba atjungti. Vienintelis efektyvus būdas valdyti šią daugiasluoksnę tikrovę yra programinė įranga.

Taigi infrastruktūra turėjo tapti kodu. Visi tie „Perl“ scenarijai rodo, kad jis jau tapo kodu jau 80-ųjų pabaigoje; iš tikrųjų „Perl“ buvo sukurta kaip programavimo kalba, skirta automatizuoti sistemos administravimą. Neilgai trukus pažangiausi sisteminiai administratoriai suprato, kad rankų darbo konfigūracijos ir neatkuriami užkalbėjimai yra blogas būdas valdyti savo parduotuves. Gali būti, kad ši tendencija reiškia tradicinių sistemos administratorių, kurių darbas sumažėja iki „Amazon“ ar „Rackspace“ sistemų kaupimo, pabaigą. Bet tai greičiausiai bus tik tų sistemų administratorių, kurie atsisako augti ir prisitaikyti, vystantis skaičiavimo pramonei, likimas. (Ir aš įtariu, kad atsisakantys prisitaikyti sysadminiai išpučia BOFH brolijos gretas, ir dauguma mūsų būtų laimingi, matydami juos paliekant.) Geri sysadminai visada suprato, kad automatika buvo reikšmingas jų darbo komponentas ir prisitaikys kaip automatika tampa dar svarbesnė. Naujasis „sysadmin“ neišjungs mašinos, pakeis sugedusį disko įrenginį, neperkraus ir neatkurs iš atsarginės kopijos; jis parašys programinę įrangą, kad automatiškai aptiktų netinkamai veikiantį EC2 egzempliorių, sunaikintų blogą egzempliorių, sukurs naują ir sukonfigūruos viską nenutraukdamas paslaugos. Esant tokio lygio automatizavimui, naujajam „ops guy“ nebus svarbu, ar jis yra atsakingas už tuziną ar 10 000 sistemų. Šiuolaikinis BOFH dažniausiai yra senosios mokyklos sistadminas, nusprendęs nesitaikyti.

Jamesas Urquhartas pritaria, kai aprašo, kaip šiuolaikinės debesyje veikiančios programos vis dar turi būti atsparios ir tolerantiškos trikdžiams, jas vis tiek reikia stebėti, vis tiek reikia prisitaikyti prie didžiulių apkrovos svyravimų ir kt. Tačiau jis pažymi, kad šios funkcijos, kurios anksčiau buvo teikiamos IT / operacijų infrastruktūros, dabar turi būti programos dalis, ypač „platformos kaip paslaugos“ aplinkoje. Operacijos niekur nedingsta, jos tampa kūrimo dalimi. Užuot įsivaizdavę kokį nors „uber“ kūrėją, kuris supranta didelius duomenis, interneto našumo optimizavimą, programų tarpinę programinę įrangą ir toleranciją gedimams masiškai paskirstytoje aplinkoje, mums reikia operacijų specialistų kūrimo komandose. Infrastruktūra niekur nedingsta – ji pereina į kodą; ir žmonės, atsakingi už infrastruktūrą, sistemos administratoriai ir korporatyvinės IT grupės vystosi taip, kad galėtų parašyti infrastruktūrą prižiūrintį kodą. Užuot izoliuoti, jie turi bendradarbiauti ir bendradarbiauti su programomis kuriančiais kūrėjais. Tai judėjimas, neoficialiai žinomas kaip „DevOps“.

Praėjusiais metais „Amazon“ nutraukta EBS veikla rodo, kaip pasikeitė „operacijų“ pobūdis. Buvo aiškiai atskiriamos įmonės, kurios kentėjo ir prarado pinigus, ir bendrovės, kurios važiavo per prastovas. Koks buvo skirtumas? Nenukentėjusios įmonės, įskaitant „Netflix“, mokėjo kurti patikimumą; jie suprato atsparumą, duomenų sklaidą visose zonose ir daugybę patikimumo inžinerijos priemonių. Be to, jie suprato, kad atsparumas yra programos savybė, ir dirbo su kūrėjų grupėmis, kad programos išliktų, kai tinklo dalys sugenda. Svarbiau nei liepsnos apie „Amazon“ paslaugas yra liudijimai, kaip protingas ir kruopštus dizainas leido programoms veikti, kol neveikė EBS. „Netflix“ sukurtas „ChaosMonkey“ yra puikus, jei ekstremalus, pavyzdys įrankio, užtikrinančio, kad sudėtinga paskirstyta programa gali išgyventi pertraukas; „ChaosMonkey“ atsitiktinai užmuša programos egzempliorius ir paslaugas. Kūrimo ir operacijų komandos bendradarbiauja siekdamos užtikrinti, kad programa būtų pakankamai tvirta, kad nesugestų ir atlaikytų nuolatinius atsitiktinius (ir pačių sukeltus!) Sutrikimus.

Kita vertus, per EBS sustabdymą niekas, kuris nebuvo „Amazon“ darbuotojas, nelietė nė vienos aparatūros. Tuo metu, JD Ilgas tviteryje parašė, kad geriausias dalykas, susijęs su EBS nutraukimu, buvo tai, kad jo vaikinai nebėgo kaip pašėlę, bandydami taisyti reikalus. Taip ir turi būti. Vis dėlto svarbu pastebėti, kuo tai skiriasi nuo veiklos praktikos prieš 20 ar net prieš 10 metų. Viskas baigėsi, kol net nebuvo sutrikimų: Svetainės, kurios su tuo sėkmingai susidorojo, turėjo patikimą programinę įrangą ir kruopščiai tvarkė savo duomenis, kad jie nebūtų priklausomi nuo vienos zonos. Ir panašiai, svetainės, kurios stengėsi atsigauti po dingimo, buvo tos, kurios nebuvo įtvirtinusios savo programų atsparumo ir neatkurdavusios duomenų skirtingose ​​zonose.

Be šio atsakomybės perskirstymo, nuo apatinių kamino sluoksnių iki pačios programos, matome ir išlaidų perskirstymą. Klaidinga manyti, kad operacijų kaina mažėja. Naujų serverių kapitalo išlaidas gali pakeisti mėnesinės „Amazon“ sąskaitos, tačiau jos vis tiek kainuoja. Tradicinių IT darbuotojų gali būti mažiau, o serverių ir darbuotojų santykis tikrai bus didesnis, tačiau taip yra todėl, kad kai kurios IT funkcijos dingo kūrimo grupėse. Klijavimas yra skystas, tačiau būtent tai ir yra esmė. Užduotis – pateikti tvirtą, stabilią programą klientams – yra ta pati. Keičiasi serverių, kuriuose veikia ta programa, vietos ir kaip jie valdomi.

Viena svarbių operacijų užduočių yra suprasti viešųjų debesų, tokių kaip „Amazon“, privačių debesų, tradicinių kolokacijų, kainų kompromisus ir kurti savo infrastruktūrą. Sunku įveikti „Amazon“, jei esate startuolis, bandantis taupyti grynuosius pinigus ir jums reikia paskirstyti ar paskirstyti techninę įrangą, kad reaguotumėte į apkrovos svyravimus. Nenorite turėti didžiulio klasterio, kad galėtumėte tvarkyti didžiausią pajėgumą, tačiau dažniausiai palikite jį nenaudojamą. Tačiau „Amazon“ nėra nebrangi ir didesnė įmonė tikriausiai gali gauti geresnį pasiūlymą nuveždama savo infrastruktūrą į apgyvendinimo įstaigą. Keletas didžiausių kompanijų kurs savo duomenų centrus. Išlaidos ir lankstumas yra svarbus kompromisas; mastelio keitimas savaime yra lėtas, kai turite fizinę aparatinę įrangą, o kai kuriate duomenų centrus, kad galėtumėte tvarkyti didžiausią apkrovą, jūsų įrenginys dažniausiai nenaudojamas. Mažesnės įmonės kurs hibridines strategijas, kai infrastruktūros dalys bus laikomos viešuose debesyse, pvz., AWS ar „Rackspace“, dalis bus teikiama privačiojo prieglobos paslaugomis, o dalis – namuose. Optimizuoti užduočių paskirstymą tarp šių įrenginių nėra paprasta; tai yra operacijų grupių provincija. Kurti programas, kurios gali efektyviai veikti hibridinėje aplinkoje: tai yra kūrėjų atsakomybė, sveikai bendradarbiaujant su operacijomis …