Ni parolas, kompreneble, pri . Se vi ne eniras detalojn, tiam la 30-an de septembro kaj la 1-an de oktobro ni okazigos konferencon pri kombinado de la procezoj de disvolviĝo, testado kaj funkciado, kaj se vi eniros detalojn, bonvolu, sub kato.
Ene de la aliro DevOps, ĉiuj partoj de la teknologia evoluo de la projekto estas interplektitaj, okazas paralele kaj influas unu la alian. Aparte gravas ĉi tie la kreado de aŭtomatigitaj evoluprocezoj, kiuj povas esti ŝanĝitaj, simulitaj kaj provitaj en reala tempo. Ĉi tio helpas vin respondi tuj al ŝanĝoj en la merkato.
En la konferenco ni volas montri kiel ĉi tiu aliro influas produktan disvolviĝon. Kiel la fidindeco kaj adaptebleco de la sistemo por la kliento estas certigitaj. Kiel DevOps ŝanĝas la strukturon kaj aliron de kompanio por organizi sian laborprocezon.
malantaŭ la scenoj
Gravas por ni scii ne nur, kion malsamaj kompanioj faras en la kadro de la aliro DevOps, sed ankaŭ kompreni kial ĉio ĉi estas farita. Tial ni invitis ne nur spertulojn aliĝi al la Programa Komitato, sed specialistoj, kiuj vidas la DevOps-diskurson de malsamaj pozicioj:
- altrangaj inĝenieroj;
- programistoj;
- teamgvidantoj;
- CTO.
Unuflanke, tio kreas malfacilaĵojn kaj konfliktojn kiam oni diskutas petojn pri raportoj. Se inĝeniero interesiĝas pri analizo de grava akcidento, tiam pli gravas por programisto kompreni kiel krei programaron, kiu funkcias en nuboj kaj infrastrukturoj. Sed konsentante, ni kreas programon, kiu estos valora kaj interesa por ĉiuj: de inĝenieroj ĝis CTO.
La celo de nia konferenco estas ne nur elekti la plej hype-raportojn, sed prezenti la ĝeneralan bildon: kiel la DevOps-aliro funkcias praktike, kian rastilon vi povas renkonti kiam vi moviĝas al novaj procezoj. Samtempe, ni konstruas la enhavan parton, malsuprenirante de la komerca problemo al specifaj teknologioj.
La konferencaj sekcioj restos la samaj kiel en .
- Infrastruktura platformo.
- Infrastrukturo kiel kodo.
- Daŭra livero.
- Reago.
- Arkitekturo en DevOps, DevOps por CTO.
- SRE-praktikoj.
- Trejnado kaj scio-administrado.
- Sekureco, DevSecOps.
- DevOps transformo.
Alvoko por Paperoj: kiajn raportojn ni serĉas
Ni kondiĉe dividis la eblan publikon de la konferenco en kvin grupojn: inĝenieroj, programistoj, sekurecaj specialistoj, teamgvidantoj kaj CTO. Ĉiu grupo havas sian propran instigon veni al la konferenco. Kaj, se vi rigardas DevOps de ĉi tiuj pozicioj, vi povas kompreni kiel enfokusigi vian temon kaj kie meti emfazon.
Por inĝenieroj, kiuj kreas infrastrukturan platformon, gravas kompreni la ekzistantajn tendencojn, kompreni kiuj teknologioj nun estas la plej progresintaj. Ili interesos lerni pri reala vivo sperto pri uzado de ĉi tiuj teknologioj kaj interŝanĝado de opinioj. Inĝeniero volonte aŭskultos raporton analizantan iun seriozan akcidenton, kaj ni, siavice, provos elekti kaj poluri tian raporton.
Por programistoj gravas kompreni tian koncepton kiel nuba denaska aplikaĵo. Tio estas, kiel disvolvi programaron por ke ĝi funkciu en nuboj kaj diversaj infrastrukturoj. La programisto devas konstante ricevi komentojn de la programaro. Ĉi tie ni volas aŭdi kazojn pri kiel kompanioj konstruas ĉi tiun procezon, kiel monitori programaran agadon kaj kiel funkcias la tuta livera procezo.
Specialistoj pri cibersekureco Gravas kompreni kiel agordi la sekurecan procezon por ke ĝi ne haltigu la evoluajn kaj ŝanĝajn procezojn ene de la kompanio. Temoj pri la postuloj kiujn DevOps metas al tiaj specialistoj ankaŭ estos interesaj.
Teamgvidantoj volas scii, kiel la kontinua livera procezo funkcias en aliaj kompanioj. Kian vojon kompanioj prenis por atingi ĉi tion, kiel ili konstruis procezojn de disvolviĝo kaj garantio de kvalito ene de DevOps. Teamgvidantoj ankaŭ interesiĝas pri Cloud-indiĝeno. Kaj ankaŭ demandoj pri interagado ene de la teamo kaj inter evoluaj kaj inĝenieraj teamoj.
Por CTO la plej grava afero estas eltrovi kiel konekti ĉiujn ĉi tiujn procezojn kaj ĝustigi ilin al komercaj bezonoj. Li certigas, ke la aplikaĵo estas fidinda kaj por la komerco kaj por la kliento. Kaj ĉi tie vi devas kompreni, kiuj teknologioj funkcios por kiuj komercaj taskoj, kiel konstrui la tutan procezon, ktp. La CTO ankaŭ respondecas pri buĝetado. Ekzemple, li devas kompreni kiom da mono devas esti elspezita por retrejni specialistojn por ke ili povu labori en DevOps.
Se vi havas ion por diri pri ĉi tiuj aferoj, ne silentu, . La limdato por Voko por Paperoj estas la 20-a de aŭgusto. Ju pli frue vi registriĝos, des pli da tempo vi devos fini vian raporton kaj prepari vian prezenton. Do, ne prokrastu.
Nu, se vi ne bezonas paroli publike, nur kaj venu la 30-an de septembro kaj la 1-an de oktobro por komuniki kun kolegoj. Ni promesas, ke ĝi estos interesa kaj inspira.
Kiel ni vidas DevOps
Por kompreni ĝuste kion ni celas per DevOps, mi rekomendas legi (aŭ relegi) mian raporton "" Promenante tra la ondoj de la merkato, mi observis kiel la ideo de DevOps transformiĝis en malsamaj grandecoj kompanioj: de malgranda starto ĝis multnaciaj kompanioj. La raporto estas konstruita sur serio de demandoj, respondante ilin vi povas kompreni ĉu via kompanio moviĝas al DevOps aŭ ĉu estas problemoj ie.
DevOps estas kompleksa sistemo, ĝi devas inkluzivi:
- Cifereca produkto.
- Komercaj moduloj, kiuj disvolvas ĉi tiun ciferecan produkton.
- Produktteamoj kiuj skribas kodon.
- Kontinuaj Liveraj praktikoj.
- Platformoj kiel servo.
- Infrastrukturo kiel servo.
- Infrastrukturo kiel kodo.
- Apartaj praktikoj por konservi fidindecon, konstruitajn en DevOps.
- Retrosciiga praktiko, kiu priskribas ĉion.
Ĉe la fino de la raporto estas diagramo, kiu donas ideon pri la sistemo DevOps en la kompanio. Ĝi permesos al vi vidi, kiuj procezoj en via kompanio jam estis simpligitaj kaj kiuj ankoraŭ estas konstruotaj.
Vi povas spekti la videon de la raporto .
Kaj nun estos gratifiko: pluraj filmetoj de RIT++ 2019, kiuj tuŝas la plej ĝeneralajn aferojn de DevOps-transformo.
Firmaa infrastrukturo kiel produkto
Artyom Naumenko gvidas la teamon DevOps ĉe Skyeng kaj prizorgas la disvolviĝon de la infrastrukturo de sia kompanio. Li rakontis kiel infrastrukturo influas komercajn procezojn ĉe SkyEng: kiel kalkuli ROI por ĝi, kiajn metrikojn oni elektu por kalkulo kaj kiel labori por plibonigi ilin.
Survoje al mikroservoj
Nixys-firmao provizas subtenon por okupataj retprojektoj kaj distribuitaj sistemoj. Ĝia teknika direktoro, Boris Ershov, rakontis kiel traduki softvaraĵojn, kies evoluo komenciĝis antaŭ 5 jaroj (aŭ eĉ pli), al moderna platformo.
Ĝenerale, tiaj projektoj estas speciala mondo, kie estas tiaj malhelaj kaj antikvaj anguloj de la infrastrukturo, ke nunaj inĝenieroj ne scias pri ili. Kaj la aliroj al arkitekturo kaj evoluo, kiuj iam estis elektitaj, estas malmodernaj kaj ne povas provizi la komercon kun la sama rapideco de disvolviĝo kaj liberigo de novaj versioj. Kiel rezulto, ĉiu produkta eldono fariĝas nekredebla aventuro, kie io konstante defalas, kaj en la plej neatendita loko.
Administrantoj de tiaj projektoj neeviteble alfrontas la bezonon transformi ĉiujn teknologiajn procezojn. En lia raporto, Boriso diris:
- kiel elekti la ĝustan arkitekturon por la projekto kaj ordigi la infrastrukturon;
- kiajn ilojn uzi kaj kiajn kaptilojn oni renkontas sur la vojo al transformiĝo;
- kion fari poste.
Aŭtomatigo de ĵetoj aŭ kiel liveri rapide kaj senpere
Alexander Korotkov estas ĉefa programisto de la CI/CD-sistemo ĉe CIAN. Li parolis pri aŭtomatigaj iloj, kiuj ebligis plibonigi kvaliton kaj redukti la tempon por liverado de kodo al produktado je 5 fojojn. Sed tiaj rezultoj ne povus esti atingitaj per aŭtomatigo sole, do Aleksandro ankaŭ atentis ŝanĝojn en evoluaj procezoj.
Kiel akcidentoj helpas vin lerni?
Alexey Kirpichnikov efektivigas DevOps kaj infrastrukturon ĉe SKB Kontur dum 5 jaroj. Dum tri jaroj, ĉirkaŭ 1000 fakapoj de ŝanĝiĝantaj gradoj da epopeo okazis en lia firmao. Inter ili, ekzemple, 36% estis kaŭzitaj de lanĉado de malaltkvalita eldono en produktadon, kaj 14% estis kaŭzitaj de aparataro prizorgado en la datumcentro.
Arkivo de raportoj (postmortems), kiujn la inĝenieroj de la kompanio konservas dum pluraj jaroj sinsekve, ebligas akiri tiajn precizajn informojn pri akcidentoj. La postmorto estas skribita de la deĵoranta inĝeniero, kiu la unua respondis al la krizsignalo kaj komencis ĉion ripari. Kial turmenti inĝenierojn, kiuj nokte luktas kun facaps verkante raportojn? Ĉi tiuj datumoj ebligas al vi vidi la tutan bildon kaj movi infrastrukturan disvolviĝon en la ĝusta direkto.
En sia parolado, Alexey konigis kiel verki vere utilan postmortan kaj kiel efektivigi la praktikon de tiaj raportoj en granda kompanio. Se vi ŝatas rakontojn pri kiel iu fuŝis, rigardu la videon de la prezentado.
Ni komprenas, ke via vizio de DevOps eble ne kongruas kun la nia. Estos interese scii kiel vi vidas transformon de DevOps. Kunhavigu vian sperton kaj vizion pri ĉi tiu temo en la komentoj.
Kiajn raportojn ni jam akceptis en la programo?
Ĉi-semajne la Programa Komitato adoptis 4 raportojn: pri sekureco, infrastrukturo kaj SRE-praktikoj.
Eble la plej dolora temo de DevOps-transformo: kiel certigi, ke la uloj de la fako pri informa sekureco ne detruas la jam konstruitajn ligojn inter disvolviĝo, operacio kaj administrado. Iuj kompanioj administras sen fako pri informa sekureco. Kiel certigi informan sekurecon en ĉi tiu kazo? Pri ĝi Mona Arkhipova el sudo.su. El ŝia raporto ni lernas:
- kio devas esti protektita kaj de kiu;
- kio estas la rutinaj sekurecaj procezoj;
- kiel IT kaj informsekurecaj procezoj intersekcas;
- kio estas CIS CSC kaj kiel efektivigi ĝin;
- kiel kaj laŭ kiuj indikiloj fari regulajn informsekurecajn kontrolojn.
La sekva raporto koncernas la evoluon de infrastrukturo kiel kodo. Redukti la kvanton de mana rutino kaj ne turni la tutan projekton en kaoso, ĉu tio eblas? Al ĉi tiu demando Maksimo Kostrikin el Ixtens. Lia kompanio uzas Terraform por labori kun AWS-infrastrukturo. La ilo estas oportuna, sed la demando estas kiel eviti krei grandegan blokon de kodo kiam oni uzas ĝin. Prizorgado de tia heredaĵo fariĝos pli kaj pli multekosta ĉiujare.
Maxim montros kiel funkcias kodaj lokigaj ŝablonoj, celante simpligi aŭtomatigon kaj disvolviĝon.
Alia ni aŭdos pri infrastrukturo de Vladimir Ryabov de Playkey. Ĉi tie ni parolos pri la infrastruktura platformo, kaj ni lernos:
- kiel kompreni ĉu konserva spaco estas uzata efike;
- kiom kelkcent uzantoj povas ricevi 10 TB da enhavo se nur 20 TB da stokado estas uzata;
- kiel kunpremi datumojn 5 fojojn kaj provizi ĝin al uzantoj en reala tempo;
- kiel sinkronigi datumojn sur la flugo inter pluraj datumcentroj;
- kiel forigi ajnan influon de uzantoj unu sur la alia kiam vi uzas unu virtualan maŝinon sinsekve.
La sekreto de ĉi tiu magio estas teknologio ZFS por FreeBSD kaj ĝia freŝa forko ZFS en Linukso. Vladimir dividos kazojn de Playkey.
Matvey Kukuy de Amixr.IO preta kun ekzemploj el la vivo , kio okazis SRE kaj kiel ĝi helpas konstrui fidindajn sistemojn. Amixr.IO pasas klientajn incidentojn tra sia backend; dekduoj da deĵorantaj teamoj tra la mondo jam traktis 150 mil kazojn. En la konferenco, Matvey dividos la statistikojn kaj komprenojn, kiujn lia kompanio amasigis solvante klientajn problemojn kaj analizante fiaskojn.
Denove mi instigas vin ne esti avida kaj dividi vian sperton kiel DevOps samurajo. Servi por raporto, kaj vi kaj mi havos 2,5 monatojn por prepari bonegan paroladon. Se vi volas esti aŭskultanto, al la bulteno kun programaj ĝisdatigoj kaj serioze pripensu rezervi biletojn anticipe, ĉar ili iĝos pli multekostaj pli proksime al la konferencaj datoj.
fonto: www.habr.com