Ni iam liveris elektronikan dokumentan administradsistemon al kliento ĉe unu instalaĵo. Kaj poste al alia objekto. Kaj unu pli. Kaj sur la kvara, kaj sur la kvina. Ni tiom forportiĝis, ke ni atingis 10 distribuitajn objektojn. Ĝi rezultis potence... precipe kiam ni atingis liveri la ŝanĝojn. Kiel parto de la livero al la produktadcirkvito, 5 scenaroj de la testa sistemo finfine postulis 10 horojn kaj 6-7 dungitojn. Tiaj kostoj devigis nin fari liveraĵojn kiel eble plej malofte. Post tri jaroj da operacio, ni ne povis elteni ĝin kaj decidis spici la projekton per pinĉo de DevOps.
Nun ĉiuj provoj okazas en 3 horoj, kaj 3 homoj partoprenas en ĝi: inĝeniero kaj du testistoj. La plibonigoj estas klare esprimitaj en nombroj kaj kondukas al redukto de la tre amata TTM. Laŭ nia sperto, estas multaj pli da klientoj, kiuj povas profiti de DevOps ol tiuj, kiuj eĉ scias pri ĝi. Tial, por alproksimigi DevOps al homoj, ni evoluigis simplan konstrukciiston, pri kiu ni parolos pli detale en ĉi tiu afiŝo.
Nun ni diru al vi pli detale. Unu energikompanio deplojas teknikan dokumentan administradsistemon ĉe 10 grandaj instalaĵoj. Ne estas facile navigi projektojn de ĉi tiu skalo sen DevOps, ĉar granda parto de mana laboro multe prokrastas la laboron kaj ankaŭ reduktas kvaliton - ĉiu mana laboro estas plena de eraroj. Aliflanke, ekzistas projektoj, kie ekzistas nur unu instalaĵo, sed ĉio devas funkcii aŭtomate, konstante kaj sen fiasko - ekzemple, la samaj dokumentfluaj sistemoj en grandaj monolitaj organizaĵoj. Alie, iu faros la agordojn permane, forgesos pri la instrukcioj pri deplojo - kaj kiel rezulto, en produktado la agordoj perdiĝos kaj ĉio kolapsos.
Kutime ni laboras kun la kliento per kontrakto, kaj ĉi-kaze niaj interesoj iomete diverĝas. La kliento rigardas la projekton strikte en la buĝeto kaj teknikaj specifoj. Povas esti malfacile klarigi al li la avantaĝojn de diversaj DevOps-praktikoj, kiuj ne estas inkluzivitaj en la teknikaj specifoj. Kio se li interesiĝas pri rapidaj eldonoj kun aldonita komerca valoro, aŭ pri konstruado de aŭtomatiga dukto?
Ve, kiam oni laboras kun antaŭaprobita kosto, ĉi tiu intereso ne ĉiam troviĝas. En nia praktiko, estis kazo kiam ni devis repreni la evoluon de senskrupula kaj senzorga entreprenisto. Estis terure: ne estis ĝisdatigitaj fontkodoj, la kodbazo de la sama sistemo estis malsama ĉe malsamaj instalaĵoj, la dokumentado estis parte forestanta, kaj parte de terura kvalito. Kompreneble, la kliento ne havis kontrolon pri la fontkodo, kunigo, eldonoj, ktp.
Ĝis nun, ne ĉiuj scias pri DevOps, sed tuj kiam ni parolas pri ĝiaj avantaĝoj, pri reala ŝparado de rimedoj, la okuloj de ĉiuj klientoj eklumiĝas. Do la nombro da petoj, kiuj inkluzivas DevOps, pliiĝas laŭlonge de la tempo. Ĉi tie, por facile paroli la saman lingvon kun klientoj, ni devas rapide konekti komercajn problemojn kaj DevOps-praktikojn, kiuj helpos konstrui taŭgan disvolvan dukton.
Do, ni havas aron da problemoj unuflanke, ni havas DevOps-scion, praktikojn kaj ilojn aliflanke. Kial ne dividi la sperton kun ĉiuj?
Kreante DevOps-konstruktilon
Agile havas sian propran manifeston. ITIL havas sian propran metodaron. DevOps estas malpli bonŝanca - ĝi ankoraŭ ne akiris ŝablonojn kaj normojn. Kvankam determini la maturecon de kompanioj surbaze de takso de ilia evoluo kaj funkciaj praktikoj.
Feliĉe, la konata kompanio Gartner en 2014 kaj analizis ŝlosilajn DevOps-praktikojn kaj la rilatojn inter ili. Surbaze de tio, mi publikigis infografion:
Ni prenis ĝin kiel bazon por nia . Ĉiu el la kvar areoj havas aron da iloj - ni kolektis ilin en datumbazon, identigis la plej popularajn, identigis integrigajn punktojn kaj taŭgajn optimumigajn mekanismojn. Entute ĝi rezultis 36 praktikoj kaj 115 iloj, el kiuj kvarono estas malfermkoda aŭ libera programaro. Poste, ni parolos pri tio, kion ni atingis en ĉiu areo kaj, kiel ekzemplo, pri kiel tio estis efektivigita en la projekto por krei teknikan dokumentan administradon, kun kiu ni komencis la afiŝon.
Procezoj
En la fifama EDMS-projekto, la teknika dokumenta administradsistemo estis deplojita laŭ la sama skemo ĉe ĉiu el la 10 objektoj. La instalaĵo inkluzivas 4 servilojn: datumbaza servilo, aplikaĵoservilo, plenteksta indeksado kaj enhavadministrado. En la instalado, ili funkcias ene de ununura nodo kaj situas en la datumcentro ĉe la instalaĵoj. Ĉiuj objektoj iomete malsamas en infrastrukturo, sed ĉi tio ne malhelpas tutmondan interagon.
Unue, laŭ DevOps-praktikoj, ni aŭtomatigis la infrastrukturon loke, poste ni alportis la liveraĵon al la testa cirkvito, kaj poste al la produkto de la kliento. Ĉiu procezo estis ellaborita paŝo post paŝo. La medio-agordoj estas fiksitaj en la fontkodsistemo, konsiderante, kiu la distribua kompleto estas kompilita por aŭtomata ĝisdatigo. En kazo de agordaj ŝanĝoj, inĝenieroj simple bezonas fari la taŭgajn ŝanĝojn al la versio-kontrolsistemo - kaj tiam la aŭtomata ĝisdatigo okazos senprobleme.
Danke al ĉi tiu aliro, la testa procezo estis tre simpligita. Antaŭe, la projekto havis testistojn, kiuj faris nenion krom permane ĝisdatigi standojn. Nun ili nur venas, vidu, ke ĉio funkcias kaj faras pli utilajn aferojn. Ĉiu ĝisdatigo estas provita aŭtomate - de la surfaca nivelo ĝis komerca scenaro aŭtomatigo. La rezultoj estas afiŝitaj kiel apartaj raportoj en TestRail.
Kulturo
Kontinua eksperimentado estas plej bone klarigita per la ekzemplo de testa dezajno. Provi sistemon kiu ankoraŭ ne ekzistas estas krea laboro. Kiam vi verkas testan planon, vi devas kompreni kiel testi ĝuste kaj kiujn branĉojn sekvi. Kaj ankaŭ trovu ekvilibron inter tempo kaj buĝeto por determini la optimuman nombron da ĉekoj. Gravas elekti ĝuste la necesajn provojn, pensi pri kiel la uzanto interagos kun la sistemo, konsideru la medion kaj eblajn eksterajn faktorojn. Estas neeble fari sen kontinua eksperimentado.
Nun pri la kulturo de interagado. Antaŭe, estis du kontraŭaj flankoj - inĝenieroj kaj programistoj. La programistoj diris: "Ni ne gravas kiel ĝi estos lanĉita. Vi estas inĝenieroj, vi estas saĝaj, certigu, ke ĝi funkcias sen fiaskoj". La inĝenieroj respondis: “Vi programistoj estas tro senzorgaj. Ni estu pli singardaj, kaj ni ludos viajn eldonojn malpli ofte. Ĉar ĉiufoje kiam vi donas al ni likan kodon, al ni ne estas klare kiel interagi.". Ĉi tio estas kultura interaga afero, kiu estas strukturita malsame de DevOps-perspektivo. Ĉi tie, kaj inĝenieroj kaj programistoj estas parto de ununura teamo, kiu koncentriĝas pri konstante ŝanĝiĝanta, sed samtempe fidinda programaro.
Ene de la sama teamo, specialistoj estas celkonsciaj helpi unu la alian. Kiel estis anta? Ekzemple, estis preparitaj kelkaj dikaj deploj instrukcioj, ĉirkaŭ 50 paĝoj longaj.La inĝeniero legis ĝin, ne komprenis ion, malbenis kaj petis la programiston je la tria horo matene komenti. La programisto komentis kaj ankaŭ malbenis - finfine neniu estis feliĉa. Krome, nature, estis iuj eraroj, ĉar vi ne povas memori ĉion en la instrukcioj. Kaj nun la inĝeniero, kune kun la programisto, skribas skripton por la aŭtomatigita deplojo de aplika programara infrastrukturo. Kaj ili parolas unu al la alia praktike en la sama lingvo.
personoj
La grandeco de la teamo estas determinita de la amplekso de la ĝisdatigo. La teamo estas rekrutita dum la formado de la liveraĵo; ĝi inkluzivas interesatojn el la ĝenerala projektteamo. Tiam ĝisdatigoplano estas skribita kun la respondecaj por ĉiu etapo, kaj la teamo raportas kiel ĝi progresas. Ĉiuj grupanoj estas interŝanĝeblaj. Kiel parto de la teamo, ni ankaŭ havas rezervan programiston, sed li preskaŭ neniam devas konektiĝi.
de teknologio
En la teknologia diagramo, kelkaj punktoj estas emfazitaj, sed sub ili estas amaso da teknologioj - oni povus eldoni tutan libron kun iliaj priskriboj. Do ni reliefigos la plej interesajn.
Infrastrukturo kiel Kodo
Nun, verŝajne, ĉi tiu koncepto ne surprizos neniun, sed antaŭe la priskriboj de infrastrukturoj lasis multe por deziri. , la testaj medioj estis unikaj, ili estis ŝatataj kaj ŝatataj, polvopartikloj estis forblovataj de ili.
Nuntempe neniu timas eksperimenti. Estas bazaj bildoj de virtualaj maŝinoj, estas pretaj scenaroj por disfaldi mediojn. Ĉiuj ŝablonoj kaj skriptoj estas konservitaj en versio-kontrolsistemo kaj estas tuj ĝisdatigitaj. Antaŭe, kiam necesis liveri pakaĵon al stando, aperis agorda breĉo. Nun vi nur bezonas aldoni linion al la fontkodo.
Krom infrastrukturaj manuskriptoj kaj duktoj, la aliro Dokumentado kiel Kodo ankaŭ estas uzata por dokumentado. Danke al ĉi tio, estas facile konekti novajn homojn al la projekto, enkonduki ilin en la sistemon surbaze de la funkcioj priskribitaj, ekzemple, en la testa plano, kaj ankaŭ reuzi testajn kazojn.
Daŭra livero kaj monitorado
pri DevOps, ni parolis pri kiel ni elektis ilojn por efektivigi kontinuan liveron kaj monitoradon. Ofte ne necesas reverki ion ajn - sufiĉas uzi antaŭe skribitajn skriptojn, ĝuste konstrui integriĝon inter komponantoj kaj krei komunan administran konzolon. Kaj ĉiuj procezoj povas esti lanĉitaj per unu butono aŭ horaro.
En la angla estas malsamaj konceptoj, Continuous Delivery kaj Continuous Deployment. Ambaŭ povas esti tradukitaj kiel "kontinua livero", sed fakte estas eta diferenco inter ili. En nia projekto por la teknika dokumentfluo de distribuita energikompanio, prefere, Liveraĵo estas uzata - kiam instalado por produktado okazas laŭ komando. En Deplojo, instalado okazas aŭtomate. Kontinua Livero en ĉi tiu projekto ĝenerale fariĝis centra parto de DevOps.
Ĝenerale, kolektante iujn parametrojn, vi povas klare kompreni kial DevOps-praktikoj estas utilaj. Kaj transdonu ĉi tion al administrado, kiu vere amas nombrojn. La totala nombro da lanĉoj, la ekzekuttempo de skriptostadioj, la proporcio de sukcesaj lanĉoj - ĉio ĉi rekte influas la plej ŝatatan tempon de ĉiuj surmerkatigado, tio estas, la tempo de transdono al la versio-kontrolsistemo ĝis la ĵeto de versio sur la merkato. produktadmedio. Kun la efektivigo de la necesaj iloj, inĝenieroj ricevas valorajn indikilojn per poŝto, kaj la projektestro vidas ilin sur la panelo. Tiel vi povas tuj taksi la avantaĝojn de novaj iloj. Kaj vi povas provi ilin en via infrastrukturo uzante la dezajniston DevOps.
Kiu bezonos nian ?
Ni ne ŝajnigu: por komenci, li fariĝis utila al ni. Kiel ni jam diris, vi devas paroli la saman lingvon kun la kliento, kaj kun la helpo de la dezajnisto DevOps ni povas rapide skizi la bazon por tia konversacio. Komercaj specialistoj povos mem taksi, kion ili bezonas kaj tiel disvolviĝi pli rapide. Ni provis fari la desegniston kiel eble plej detala, aldonante amason da priskriboj por ke iu ajn uzanto komprenu kion li elektas.
La formato de la dezajnisto permesas al vi konsideri la ekzistantajn evoluojn de la kompanio en konstruaj procezoj kaj aŭtomatigo. Ne necesas malkonstrui ĉion kaj rekonstrui ĝin, se vi nur povas elekti solvojn, kiuj bone integriĝas kun ekzistantaj procezoj kaj kiuj simple povas plenigi la mankojn.
Eble via evoluo jam moviĝis al pli alta nivelo kaj nia ilo ŝajnos tro "kapitana". Sed ni trovas ĝin utila por ni mem kaj esperas, ke ĝi estos utila al kelkaj el la legantoj. Ni memorigas vin al la dezajnisto - se io ajn, vi ricevas la diagramon tuj post enigo de la komencaj datumoj. Ni estos dankemaj pro viaj komentoj kaj aldonoj.
fonto: www.habr.com