Direktoro de Operacioj de la portalo Banki.ru Andrey Nikolsky parolis en la pasintjara konferenco pri orfaj servoj: kiel identigi orfon en la infrastrukturo, kial orfaj servoj estas malbonaj, kion fari kun ili, kaj kion fari se nenio helpas.
Sub la tranĉo estas teksta versio de la raporto.
Saluton kolegoj! Mi nomiĝas Andrey, mi gvidas operaciojn ĉe Banki.ru.
Ni havas grandajn servojn, ĉi tiuj estas tiaj monolitaj servoj, ekzistas servoj en pli klasika signifo, kaj estas tre malgrandaj. En mia laborista-kamparana terminologio, mi diras, ke se servo estas simpla kaj malgranda, tiam ĝi estas mikro, kaj se ĝi ne estas tre simpla kaj malgranda, tiam ĝi estas nur servo.
Avantaĝoj de servoj
Mi rapide trarigardos la avantaĝojn de la servoj.
La unua estas grimpi. Vi povas rapide fari ion pri la servo kaj komenci produktadon. Vi ricevis trafikon, vi klonis la servon. Vi havas pli da trafiko, vi klonis ĝin kaj vivas kun ĝi. Ĉi tio estas bona gratifiko, kaj principe, kiam ni komencis, ĝi estis konsiderita la plej grava afero por ni, kial ni faras ĉion ĉi.
Due, izolita disvolviĝo, kiam vi havas plurajn evoluigajn teamojn, plurajn malsamajn programistojn en ĉiu teamo, kaj ĉiu teamo disvolvas sian propran servon.
Kun teamoj estas nuanco. Programistoj estas malsamaj. Kaj ekzistas, ekzemple, . Mi unue vidis ĉi tion kun Maksim Dorofeev. Foje neĝfloko homoj estas en iuj teamoj kaj ne en aliaj. Ĉi tio faras la malsamajn servojn uzatajn tra la kompanio iom malebenaj.
Rigardu la bildon: ĉi tiu estas bona programisto, li havas grandajn manojn, li povas fari multon. La ĉefa problemo estas de kie venas ĉi tiuj manoj.
Servoj ebligas uzi malsamajn programlingvojn, kiuj pli taŭgas por malsamaj taskoj. Iu servo estas en Go, iuj estas en Erlang, iuj estas en Ruby, io estas en PHP, io estas en Python. Ĝenerale, vi povas vastigi tre vaste. Ankaŭ ĉi tie estas nuancoj.
Servo-orientita arkitekturo temas ĉefe pri devopoj. Tio estas, se vi ne havas aŭtomatigon, ne ekzistas procezo de deplojo, se vi agordas ĝin permane, viaj agordoj povas ŝanĝiĝi de servo-instanco al ekzemplo, kaj vi devas iri tien por fari ion, tiam vi estas en la infero.
Ekzemple, vi havas 20 servojn kaj vi devas deploji mane, vi havas 20 konzolojn, kaj vi samtempe premas "enigi" kiel Ŝinobo. Ĝi ne estas tre bona.
Se vi havas servon post testado (se estas testado, kompreneble), kaj vi ankoraŭ bezonas fini ĝin per dosiero por ke ĝi funkciu en produktado, mi ankaŭ havas malbonajn novaĵojn por vi.
Se vi fidas je specifaj Amazon-servoj kaj laboras en Rusio, tiam antaŭ du monatoj vi ankaŭ havis "Ĉio ĉirkaŭe brulas, mi fartas bone, ĉio estas bonega."
Ni uzas Ansible por aŭtomatigi deplojon, Puppet por konverĝo, Bambuo por aŭtomatigi deplojon, kaj Confluence por iel priskribi ĉion.
Mi ne detale detale pri tio, ĉar la raporto temas pli pri interagaj praktikoj, kaj ne pri teknika efektivigo.
Ekzemple, ni havis problemojn kie Puppet sur la servilo funkcias kun Ruby 2, sed iu aplikaĵo estas skribita por Ruby 1.8, kaj ili ne funkcias kune. Io misfunkcias tie. Kaj kiam vi bezonas ruli plurajn versiojn de Ruby sur unu maŝino, vi kutime komencas havi problemojn.
Ekzemple, ni donas al ĉiu programisto platformon sur kiu estas proksimume ĉio, kion ni havas, ĉiuj servoj evolueblaj, por ke li havu izolan medion, li povu rompi ĝin kaj konstrui ĝin kiel li volas.
Okazas, ke vi bezonas iun speciale kompilitan pakaĵon kun subteno por io tie. Ĝi estas sufiĉe malfacila. Mi aŭskultis raporton, kie la bildo de Docker pezas 45 GB. En Linukso, kompreneble, ĝi estas pli simpla, ĉio estas pli malgranda tie, sed tamen, ne estos sufiĉe da spaco.
Nu, estas konfliktantaj dependecoj, kiam unu peco de la projekto dependas de biblioteko de unu versio, alia peco de la projekto dependas de alia versio, kaj la bibliotekoj tute ne estas instalitaj kune.
Ni havas retejojn kaj servojn en PHP 5.6, ni hontas pri ili, sed kion ni povas fari? Ĉi tiu estas nia unu retejo. Estas retejoj kaj servoj en PHP 7, estas pli da ili, ni ne hontas pri ili. Kaj ĉiu programisto havas sian propran bazon, kie li feliĉe segas.
Se vi skribas en firmao en unu lingvo, tiam tri virtualaj maŝinoj per programisto sonas normale. Se vi havas malsamajn programlingvojn, tiam la situacio plimalboniĝas.
Vi havas retejojn kaj servojn pri ĉi tio, sur ĉi tio, tiam alian retejon por Go, unu retejon por Ruby, kaj iuj aliaj Redis flanke. Kiel rezulto, ĉio ĉi iĝas granda kampo por subteno, kaj la tutan tempon iom el ĝi povas rompi.
Tial ni anstataŭigis la avantaĝojn de la programlingvo per la uzo de malsamaj kadroj, ĉar PHP-kadroj estas sufiĉe malsamaj, ili havas malsamajn kapablojn, malsamajn komunumojn kaj malsaman subtenon. Kaj vi povas skribi servon, por ke vi jam havu ion pretan por ĝi.
Ĉiu servo havas sian propran teamon
Nia ĉefa avantaĝo, kiu kristaliĝis dum pluraj jaroj, estas, ke ĉiu servo havas sian propran teamon. Ĉi tio estas oportuna por granda projekto, vi povas ŝpari tempon pri dokumentado, administrantoj bone konas sian projekton.
Vi povas facile sendi taskojn de subteno. Ekzemple, la asekurservo paneis. Kaj tuj la teamo, kiu okupiĝas pri asekuro, iras ripari ĝin.
Novaj funkcioj estas kreataj rapide, ĉar kiam vi havas unu atoman servon, vi povas rapide ŝraŭbi ion en ĝin.
Kaj kiam vi rompas vian servon, kaj ĉi tio neeviteble okazas, vi ne influis la servojn de aliaj homoj, kaj programistoj de aliaj teamoj ne venas al vi kun pecoj kaj diras: "Jes, ne faru tion."
Kiel ĉiam, estas nuancoj. Ni havas stabilajn teamojn, manaĝeroj estas najlitaj al la teamo. Estas klaraj dokumentoj, administrantoj atente kontrolas ĉion. Ĉiu teamo kun manaĝero havas plurajn servojn, kaj ekzistas specifa punkto de kompetenteco.
Se la teamoj flosas (ni ankaŭ foje uzas ĉi tion), ekzistas bona metodo nomata "stelmapo".
Vi havas liston de servoj kaj homoj. Asterisko signifas, ke la persono estas fakulo pri ĉi tiu servo, libro signifas, ke la persono studas ĉi tiun servon. La tasko de la persono estas ŝanĝi la libreton por asterisko. Kaj se nenio estas skribita antaŭ la servo, tiam komenciĝas problemoj, pri kiuj mi parolos plu.
Kiel aperas orfaj servoj?
La unua problemo, la unua maniero akiri orfan servon en via infrastrukturo estas maldungi homojn. Ĉu iu iam havis komercon plenumi templimojn antaŭ ol taskoj estis taksitaj? Foje okazas, ke limdatoj estas streĉaj kaj simple ne estas sufiĉe da tempo por dokumentado. "Ni devas transdoni la servon al produktado, tiam ni aldonos ĝin."
Se la teamo estas malgranda, okazas, ke ekzistas unu programisto, kiu skribas ĉion, la ceteraj estas en la flugiloj. "Mi skribis la bazan arkitekturon, ni aldonu la interfacojn." Tiam iam la administranto, ekzemple, foriras. Kaj dum ĉi tiu periodo, kiam la administranto foriris kaj nova ankoraŭ ne estis nomumita, la programistoj mem decidas kien iras la servo kaj kio okazas tie. Kaj kiel ni scias (ni reiru kelkajn diapozitivojn), en iuj teamoj estas neĝflokaj homoj, foje neĝfloko gvidas. Tiam li rezignas, kaj ni ricevas orfan servon.
Samtempe, taskoj de subteno kaj de komerco ne malaperas; ili finiĝas en la restaro. Se estis iuj arkitekturaj eraroj dum la disvolviĝo de la servo, ili ankaŭ finiĝas en la restaro. La servo malrapide malboniĝas.
Kiel identigi orfon?
Ĉi tiu listo bone priskribas la situacion. Kiu lernis ion pri ilia infrastrukturo?
Pri dokumentitaj laboroj: ekzistas servo kaj, ĝenerale, ĝi funkcias, ĝi havas dupaĝan manlibron pri kiel labori kun ĝi, sed neniu scias kiel ĝi funkcias interne.
Aŭ, ekzemple, ekzistas ia ligmallongigilo. Ekzemple, ni nuntempe havas tri ligilojn uzatajn por malsamaj celoj en malsamaj servoj. Ĉi tiuj estas nur la konsekvencoj.
Nun mi estos la kapitano de la evidenta. Kion oni faru? Unue, ni devas transdoni la servon al alia administranto, alia teamo. Se via teamestro ankoraŭ ne ĉesis, tiam en ĉi tiu alia teamo, kiam vi komprenas, ke la servo estas kiel orfo, vi devas inkluzivi iun, kiu komprenas almenaŭ ion pri ĝi.
La ĉefa afero: vi devas havi la transigajn procedurojn skribitaj en sango. En nia kazo, mi kutime kontrolas ĉi tion, ĉar mi bezonas ĉion por funkcii. Administrantoj bezonas, ke ĝi estu liverata rapide, kaj kio okazas al ĝi poste ne plu estas tiel grava por ili.
La sekva maniero fari orfon estas "Ni faros ĝin subkontraktita, ĝi estos pli rapida, kaj poste ni transdonos ĝin al la teamo." Estas certe ke ĉiuj havas iujn planojn en la teamo, turno. Ofte komerca kliento pensas, ke la subkontraktanto faros la saman aferon kiel la teknika fako, kiun la kompanio havas. Kvankam iliaj instigiloj estas malsamaj. Estas strangaj teknologiaj solvoj kaj strangaj algoritmaj solvoj en subkontraktado.
Ekzemple, ni havis servon, kiu havis Sfinkson en diversaj neatenditaj lokoj. Mi diros al vi poste, kion mi devis fari.
Subkontraktantoj havas memskribitajn kadrojn. Ĉi tio estas nur nuda PHP kun kopio-gluo de antaŭa projekto, kie vi povas trovi ĉiajn aferojn. Deplojaj skriptoj estas granda malavantaĝo kiam vi bezonas uzi iujn kompleksajn Bash-skriptojn por ŝanĝi plurajn liniojn en iu dosiero, kaj ĉi tiuj deplojaj skriptoj estas nomitaj de iu tria skripto. Kiel rezulto, vi ŝanĝas la disfaldan sistemon, elektas ion alian, saltu, sed via servo ne funkcias. Ĉar tie estis necese meti 8 pliajn ligilojn inter malsamaj dosierujoj. Aŭ okazas, ke mil diskoj funkcias, sed cent mil ne plu funkcias.
Mi daŭre estos kapitano. Akcepti subkontraktitan servon estas deviga proceduro. Ĉu iu iam havis subkontraktitan servon alveni kaj ne esti akceptita ie ajn? Ĉi tio ne estas tiel populara, kompreneble, kiel orfa servo, sed tamen.
La servo devas esti kontrolita, la servo devas esti reviziita, pasvortoj devas esti ŝanĝitaj. Ni havis kazon kiam ili donis al ni servon, ekzistas administra panelo "se ensalutu == 'administranto' && pasvorto == 'administranto'...", ĝi estas skribita ĝuste en la kodo. Ni sidas kaj pensas, kaj homoj skribas ĉi tion en 2018?
Provi stokkapablon ankaŭ estas necesa afero. Vi devas rigardi, kio okazos sur cent mil diskoj, eĉ antaŭ ol vi metis ĉi tiun servon en produktadon ie.
Ne devus esti honto sendi servon por plibonigo. Kiam vi diras: "Ni ne akceptos ĉi tiun servon, ni havas 20 taskojn, faru ilin, tiam ni akceptos", tio estas normala. Via konscienco ne devas esti vundita de la fakto, ke vi starigas administranton aŭ ke la komerco malŝparas monon. La komerco tiam elspezos pli.
Ni havis kazon kiam ni decidis subkontrakti pilotprojekton.
Ĝi estis liverita ĝustatempe, kaj ĉi tio estis la nura kvalita kriterio. Tial ni faris alian pilotprojekton, kiu eĉ ne estis vere piloto plu. Ĉi tiuj servoj estis akceptitaj, kaj per administraj rimedoj ili diris, jen via kodo, jen la teamo, jen via administranto. La servoj fakte jam komencis fari profiton. Samtempe, fakte, ili estas ankoraŭ orfoj, neniu komprenas kiel ili funkcias, kaj administrantoj faras sian eblon por malakcepti siajn taskojn.
Estas alia bonega koncepto - gerila evoluo. Kiam iu fako, kutime la merkata fako, volas testi hipotezon kaj ordigas la tutan servon subkontraktitan. Trafiko ekfluas en ĝin, ili fermas la dokumentojn, subskribas dokumentojn kun la entreprenisto, ekfunkcias kaj diras: "Kaj, ni havas servon ĉi tie, ĝi jam havas trafikon, ĝi alportas al ni monon, ni akceptu ĝin." Ni estis kiel, "Oppa, kiel tio povas esti."
Kaj alia maniero akiri orfan servon: kiam iu teamo subite trovas sin ŝarĝita, administrado diras: "Ni transdonu la servon de ĉi tiu teamo al alia teamo, ĝi havas pli malgrandan ŝarĝon." Kaj tiam ni translokigos ĝin al tria teamo kaj ŝanĝos la administranton. Kaj fine ni denove havas orfon.
Kio estas la problemo kun orfoj?
Kiu ne scias, ĉi tiu estas la ŝirmita Wasa levita en Svedio, fama pro tio, ke ĝi sinkis 5 minutojn post lanĉo. Kaj la Reĝo de Svedio, cetere, neniun ekzekutis pro tio. Ĝi estis konstruita de du generacioj de inĝenieroj, kiuj ne sciis kiel konstrui tiajn ŝipojn. Natura efiko.
La ŝipo povus esti sinki, cetere, en multe pli malbona maniero, ekzemple, kiam la reĝo jam rajdis sur ĝi ie en ŝtormo. Kaj tiel, li tuj dronis, laŭ Agile estas bone malsukcesi frue.
Se ni malsukcesas frue, kutime ne estas problemoj. Ekzemple, dum akcepto ĝi estis sendita por revizio. Sed se ni malsukcesas jam en produktado, kiam mono estas investita, tiam povas esti problemoj. Konsekvencoj, kiel ili estas nomataj en komerco.
Kial orfaj servoj estas danĝeraj:
- La servo eble rompiĝos subite.
- La servo bezonas longan tempon por ripari aŭ tute ne estas riparita.
- Sekurecaj problemoj.
- Problemoj kun plibonigoj kaj ĝisdatigoj.
- Se grava servo malfunkcias, la reputacio de la firmao suferas.
Kion fari kun orfaj servoj?
Mi ripetos kion fari denove. Unue, devas esti dokumentaro. 7 jaroj ĉe Banki.ru instruis min, ke testistoj ne devas preni la vorton de la programistoj, kaj operacioj ne devas preni la vorton de ĉiuj. Ni devas kontroli.
Due, necesas skribi interagajn diagramojn, ĉar okazas, ke servoj ne tre bone akceptitaj enhavas dependecojn, pri kiuj neniu diris. Ekzemple, la programistoj instalis la servon sur sia ŝlosilo al iuj Yandex.Maps aŭ Dadata. Vi elĉerpigis liberan limon, ĉio rompiĝis, kaj vi tute ne scias kio okazis. Ĉiuj tiaj rastiloj devas esti priskribitaj: la servo uzas Dadata, SMS, ion alian.
Trie, labori kun teknika ŝuldo. Kiam vi faras ian lambastonojn aŭ akceptas servon kaj diras, ke io devas esti farita, vi devas certigi, ke ĝi estas farita. Ĉar tiam povas rezulti, ke la malgranda truo ne estas tiel malgranda, kaj vi falos tra ĝi.
Kun arkitekturaj taskoj, ni havis rakonton pri Sfinkso. Unu el la servoj uzis Sfinkson por eniri listojn. Nur paĝigita listo, sed ĝi estis reindeksita ĉiunokte. Ĝi estis kunmetita el du indeksoj: unu granda estis indeksita ĉiunokte, kaj estis ankaŭ malgranda indekso kiu estis ŝraŭbita al ĝi. Ĉiutage, kun 50% probablo de aŭ bombado aŭ ne, la indekso kraŝis dum la kalkulo, kaj niaj novaĵoj ĉesis ĝisdatigi sur la ĉefa paĝo. Komence necesis 5 minutoj por reindeksiĝi la indekso, poste la indekso kreskis, kaj iam ĝi komencis reindeksiĝi dum 40 minutoj. Kiam ni eltranĉis ĉi tion, ni spiris trankvile, ĉar estis klare, ke iom pli da tempo pasos kaj nia indekso estos reindeksita plentempe. Ĉi tio estos fiasko por nia portalo, ne estas novaĵoj dum ok horoj - jen, komerco ĉesis.
Planu labori kun orfa servo
Fakte, ĉi tio estas tre malfacile fari, ĉar devops temas pri komunikado. Vi volas esti en bonaj rilatoj kun viaj kolegoj, kaj kiam vi trafas viajn kolegojn kaj administrantojn super la kapon per regularoj, ili povas havi konfliktajn sentojn al tiuj homoj, kiuj faras tion.
Aldone al ĉiuj ĉi punktoj, estas alia grava afero: specifaj homoj devas respondeci pri ĉiu specifa servo, por ĉiu specifa sekcio de la deploja proceduro. Kiam mankas homoj kaj vi devas allogi iujn aliajn homojn por studi ĉi tiun tutan aferon, ĝi fariĝas malfacila.
Se ĉio ĉi ne helpis, kaj via orfa servo ankoraŭ estas orfo, neniu volas preni ĝin, dokumentaro ne estas skribita, la teamo, kiu estis vokita en ĉi tiun servon, rifuzas fari ion ajn, estas simpla maniero - refari. ĉio.
Tio estas, vi prenas la postulojn por la servo denove kaj verkas novan servon, pli bonan, sur pli bona platformo, sen strangaj teknologiaj solvoj. Kaj vi migras al ĝi en batalo.
Ni havis situacion, kiam ni prenis servon sur Yii 1 kaj rimarkis, ke ni ne povus disvolvi ĝin plu, ĉar ni elĉerpigis programistojn, kiuj povus skribi bone sur Yii 1. Ĉiuj programistoj skribas bone sur Symfony XNUMX. Kion fari? Ni asignis tempon, asignis teamon, asignis administranton, reverkis la projekton kaj glate ŝanĝis trafikon al ĝi.
Post ĉi tio, la malnova servo povas esti forigita. Ĉi tiu estas mia plej ŝatata proceduro, kiam vi devas preni kaj purigi iun servon de la agorda administra sistemo kaj poste trairi kaj vidi, ke ĉiuj aŭtoj en produktado estas malŝaltitaj, por ke la programistoj ne havu spurojn. La deponejo restas en Git.
Ĉi tio estas ĉio, pri kio mi volis paroli, mi pretas diskuti, la temo estas holivar, multaj naĝis en ĝi.
La lumbildoj diris, ke vi unuigis lingvojn. Ekzemplo estis la regrandigo de bildoj. Ĉu vere necesas strikte limigi ĝin al unu lingvo? Ĉar bildo regrandigo en PHP, nu, efektive povus esti farita en Golang.
Fakte, ĝi estas laŭvola, kiel ĉiuj praktikoj. Eble, en iuj kazoj, ĝi estas eĉ nedezirinda. Sed vi devas kompreni, ke se vi havas teknikan fakon en kompanio de 50 homoj, 45 el ili estas PHP-specialistoj, aliaj 3 estas devopoj, kiuj konas Python, Ansible, Puppet kaj ion similan, kaj nur unu el ili skribas en iuj. speco de lingvo. iu servo de regrandigo de bildoj Go, tiam kiam ĝi foriras, la kompetenteco akompanas ĝin. Kaj samtempe, vi devos serĉi merkat-specifan programiston, kiu konas ĉi tiun lingvon, precipe se ĝi estas malofta. Tio estas, el organiza vidpunkto, tio estas problema. De devops-punkto, vi ne nur bezonos kloni iun pretan aron de ludlibroj, kiujn vi uzas por disfaldi servojn, sed vi devos reskribi ilin.
Ni nuntempe konstruas servon ĉe Node.js, kaj ĉi tio estos nur platformo proksima por ĉiu programisto kun aparta lingvo. Sed ni sidis kaj pensis, ke la ludo valoras la kandelon. Tio estas, ĉi tio estas demando por ke vi sidu kaj pripensu.
Kiel vi kontrolas viajn servojn? Kiel vi kolektas kaj kontrolas protokolojn?
Ni kolektas protokolojn en Elasticsearch kaj metas ilin en Kibana, kaj depende ĉu temas pri produktado aŭ testaj medioj, malsamaj kolektantoj estas uzataj tie. Ie Lumberjack, ie aliloke io alia, mi ne memoras. Kaj estas ankoraŭ kelkaj lokoj en iuj servoj, kie ni instalas Telegraf kaj pafas aliloke aparte.
Kiel vivi kun Puppet kaj Ansible en la sama medio?
Fakte, ni nun havas du mediojn, unu estas Puppet, la alia estas Ansible. Ni laboras por hibridigi ilin. Ansible estas bona kadro por komenca aranĝo, Puppet estas malbona kadro por komenca aranĝo ĉar ĝi postulas praktikan laboron rekte sur la platformo, kaj Puppet certigas konverĝon de agordo. Ĉi tio signifas, ke la platformo konservas sin en ĝisdatigita stato, kaj por ke la ansibiligita maŝino estu ĝisdatigita, vi devas ruli ludlibrojn sur ĝi la tutan tempon kun iom da ofteco. Jen la diferenco.
Kiel vi konservas kongruecon? Ĉu vi havas agordojn en kaj Ansible kaj Puppet?
Ĉi tio estas nia granda doloro, ni konservas kongruon kun niaj manoj kaj pensas pri kiel pluiri de ĉio ĉi ie nun. Montriĝas, ke Puppet ruliĝas pakaĵojn kaj konservas iujn ligilojn tie, kaj Ansible, ekzemple, ruliĝas la kodon kaj ĝustigas la plej novajn aplikaĵajn agordojn tie.
La prezento temis pri malsamaj versioj de Ruby. Kia solvo?
Ni renkontis ĉi tion en unu loko, kaj ni devas konservi ĝin en niaj kapoj la tutan tempon. Ni simple malŝaltis la parton kiu funkciis sur la Ruby kiu estis nekongrua kun la aplikoj kaj konservis ĝin aparta.
La ĉi-jara konferenco okazos la 7-an de decembro ĉe Technopolis. Ni akceptas petojn por raportoj ĝis la 11-a de novembro. nin se vi volus paroli.
Aliĝo por partoprenantoj estas malfermita, aliĝu al ni!
fonto: www.habr.com