🥇Mantojuma pakalpojumi jūsu infrastruktūrā

Sveiki! Mani sauc Pasha Černjaks, esmu vadošais izstrādātājs QIWI, un šodien es gribu runāt par neizbēgamo. Par Legacy.

Sāksim ar jautājumu: kas ir Legacy pakalpojums? Legacy pakalpojums ir pakalpojums, ko izstrādātājs nav pieskāries nedēļu/mēnesi/gadu? Vai tas tomēr ir pakalpojums, ko uzrakstījis mazāk pieredzējis programmētājs, piemēram, tieši jūs, bet pirms gada? Un tagad jūs esat daudz labāks un pieredzējušāks. Vai tomēr Legacy pakalpojums ir tāds, kuru jūs izlēmāt nekad vairs neaktualizēt un lēnām gatavojat tam aizvietojumu? Katrā ziņā, atstāt šādu pakalpojumu bez uzraudzības un neaktualizēt to ir bumbas ar aizturi, kas var uzsprāgt vēlāk.

Pirms pārejām pie tā, kā mēs QIWI strādājam ar mūsu Legacy pakalpojumiem, es pastāstīšu, kā mēs sakārtojām pakalpojumus Viedtālrunī. Jau divus gadus esmu atbildīgs par tā darbību. Ja rodas kāda problēma, pirmkārt, vienmēr zvana man. Parasti man trūkst drosmes 11 vakarā piezvanīt kādam citam, tāpēc ir nācies sēdēt un izpētīt visus mūsu domēna pakalpojumus.

Bet es, tāpat kā jebkurš cilvēks, mīlu gulēt naktī, tāpēc centos saprast ekspluatāciju: "Puiši, kāpēc zvanāt man?" Uz ko saņēmu diezgan lakonisku atbildi: "Kam vēl?". Jo es laboju pakalpojumus, un puiši bieži vien vienkārši nezināja, kam zvanīt.

Tāpēc vienā no Viedtālruņa backend komandas retrospektīvām nolēmām izveidot tabulu, kurā ir norādīts mūsu pakalpojumu, mikropakalpojumu un monolītu saraksts, kā arī atbildīgie par tiem. Tabulas ir tiešām noderīgas, saprātīgos ierobežojumos.

Papildus informācijai par to, kurš par ko atbild, tur bija atbildes uz jautājumiem: kas ir pakalpojuma īpašnieks, kurš atbild par tā attīstību, arhitektūru un dzīves ciklu. Cilvēki, kas atbild par šo pakalpojumu, ir cilvēki, kuri var to salabot, ja nepieciešams. Pakalpojuma īpašniekam ir tiesības atstāt +2 komitos, bet atbildīgajiem arī obligāti jābūt klāt revīzijās, pirms šis pakalpojums pieņem jaunu komitu.

Laiks gāja, sākām ieviest jaunas prakses, piemēram, migrāciju uz Kubernetes, dažādus checkstyle, spotbugs, ktlint, logu pieejamību Kibana, autodiscovery pakalpojumus, nevis tiešu adresu norādīšanu un citas noderīgas lietas. Un visur mūsu tabula ļāva uzturēt mūsu pakalpojumu aktualitāti. Mums tas ir tāds kontrolsaraksts, kas saka, ka šis pakalpojums ir spējīgs darīt to, bet to vēl nevar. Taču mēs devāmies tālāk, saprazdami, ka mums trūkst informācijas par mūsu pakalpojumiem, ko mēs uzraugām, kur atrodas pakalpojuma avoti, kur norisinās būvniecības uzdevumi TeamCity, kā tie tiek izvietoti, kur uzglabājas end2end testu avoti, fotoattēli par arhitektūru, pieņemtiem lēmumiem. Ideālā gadījumā vēlējāmies, lai visa šī informācija būtu pieejama vienuviet, kad tā nepieciešama. Tādēļ mūsu tabula kļuva par izejas punktu informācijas meklējumos.

Tomēr QIWI, lai arī saglabā start-up garu, ir liela kompānija. Mums jau ir 12 gadi, un komandas mainās: cilvēki aiziet, cilvēki nāk, veidojas jaunas komandas. Un mēs atklājām savā domēnā vairākus pakalpojumus, kas ir nonākuši pie mums mantojumā. Daži šķērsoja no citu komandu izstrādātājiem, citi vienkārši kaut kādā veidā attiecās uz Mac wallet, tāpēc pakalpojums tagad ir mūsu bilancē. Kāpēc apspriest, kas un kā strādā? Pakalpojums taču strādā, un mums ir produktīvas funkcijas, kuras noteikti jāizdara.

Kā nu godi.

Bet kādā brīdī mēs atklājam, ka pakalpojums pārstāj pildīt savu funkciju, kaut kas ir salūzis — kā rīkoties šādā situācijā? Pakalpojums vienkārši ir pārstājis strādāt. Pilnīgi. Un mēs par to uzzinājām, pirmkārt, nejauši, otrkārt, pēc sešiem mēnešiem. Tā nu ir. Vienīgais, ko mēs zinājām — uz kādām virtuālajām mašīnām ir izvietots pakalpojums, kur atrodas tā avoti, un viss. Mēs veicam git clone un ienirstam cilvēka domās, kurš to rakstīja pirms vairākiem gadiem, bet ko mēs redzam? Nekā ikdienišķā mūsu Spring Boot, kaut arī esam pieraduši pie visa, mums ir pilna kaudze un viss tāds. Varbūt tur ir Spring Framework? Bet nē.

Puišis, kurš to visu rakstīja, bija stingrs un rakstīja visu tīrā Java. Nav nekādu ierastu izstrādātāja rīku, un rodas ideja - varbūt to visu vajadzētu pārrakstīt. Mums taču ir mikropakalpojumi, un no katra tosta tīkla izskan ierastā: „Puiši, mikropakalpojumi - tas ir tas, kas jums nepieciešams!” Ja gadījumā kaut kas nav kārtībā, jūs mierīgi varat paņemt jebkuru valodu, un viss būs lieliski.

Problēma ir tāda, ka šobrīd mums nav pasūtītāja, kurš atbild par šo pakalpojumu. Kādi bija viņa biznesa prasības, ko vispār šim pakalpojumam vajadzētu darīt? Un pakalpojums ir cieši integrēts jūsu biznesa procesos.

Un tagad pasakiet, cik viegli ir pārrakstīt pakalpojumu, nezinot tā biznesa prasības? Pakalpojums ir neskaidri reģistrēts, vai ir kādas metriku - nezinu. Kādas tās ir, ja tādas vispār ir - vēl jo vairāk nezinu. Un tajā pašā laikā pakalpojumā ir milzīgs skaits neskaidras biznesa loģikas klašu. Kaut kas nonāk kādā datu bāzē, par kuru mēs arī pagaidām neko nezinām.

Ar ko gan sākt?

Sākumā no loģiskākā - no testu esamības. Tur parasti ir vismaz kāda loģika, un var izdarīt secinājumus par to, kas notiek. Tagad ir modē TDD, bet mēs redzam, ka pirms 5 gadiem bija praktiski tāpat kā šobrīd: vienību testu gandrīz nav, un tie arī neteiks mums neko. Nu, izņemot kādas pārbaudes, kā tiek parakstīts kāds xml ar kādu pielāgotu sertifikātu.

Kodu saprast neizdevās, tāpēc nolēmām paskatīties, kas notiek virtuālajā mašīnā. Atvērām pakalpojuma žurnālus un atradām tajos http-klienta kļūdu, pašparakstīts sertifikāts, kas bija iebūvēts lietojumprogrammas resursos, ir beidzies derīguma termiņš. Sazinājāmies ar mūsu analītiķiem, viņi lūdza jaunu sertifikātu, to izsniedza, un pakalpojums atkal darbojas. It kā viss būtu beidzies. Vai varbūt nē? Galu galā pakalpojums darbojas, veic kādu funkciju, kas ir nepieciešama mūsu biznesam. Mums ir noteikti lietojumprogrammu izstrādes standarti, kurus, visticamāk, ievērojat arī jūs. Piemēram, neglabāt žurnālus uz mezgla mapē, bet glabāt kādā krātuvē, piemēram, Elastic, un skatīties uz tiem Kibana. Varam atcerēties arī zelta metrikas. Proti, slodze uz pakalpojumu, pieprasījumu skaits uz pakalpojumu, vai tas ir dzīvs vai nedzīvs, kā norit viņa HealthCheck. Vismaz šīs metriki palīdzēs noskaidrot, kad to var mierīgi izņemt no ekspluatācijas un aizmirst kā slikto sapni.

Ko darīt

Tāpēc mēs pievienojam tādu veco pakalpojumu tabulai, un pēc tam ejam meklēt starp izstrādātājiem brīvprātīgos, kas rūpēsies par pakalpojumu un sakārtos to: uzrakstīs vismaz kādu informāciju par pakalpojumu, pievienos saites uz grafana vadības paneļiem, uz būvēšanas uzdevumiem, sapratīs, kā izvērst lietojumu, jo nevar taču rokas tieši ar ftp pacelt failus.

Galvenais ir tas, cik ilgs laiks šī visa brīvprātīgā aktivitāte prasīs? Viens sprintam, vairāk vai mazāk pieredzējušam izstrādātājam, piemēram, 20% tehniskā parāda laikā. Bet cik laika pagāja, lai saprastu visu sarežģīto loģiku saziņai ar kādu valsts sistēmu, un ievietotu to jaunākās tehnoloģijās? Es par to nenodrošinu, varbūt mēnesis, varbūt divi komandas darbs. To saku, balstoties uz pašreizējo pieredzi ar kādu jaunu pakalpojumu integrēšanu.

Neskatoties uz to, bizness no tā nekādu vērtību nesaņem. Pilnīgi. Paņemt pakalpojumu apkalpošanai un tērēt tam nedaudz laika ir normāli. Bet pēc mūsu standartiem pakalpojuma apstrādes mēs pievienojām to tabulai, pievienojām informāciju par to un, iespējams, kādreiz pārrakstīsim. Bet šobrīd tas atbilst mūsu pakalpojumu darbības standartiem.

Kā rezultātā gribētu nonākt pie kaut kāda plāna par to, ko darīt ar novecojušiem pakalpojumiem.

Pārrakstīt novecojušos no nulles ir slikta ideja.
Patiesi, par to var nemaz nedomāt. Ir skaidrs, ka gribētos un redzami daži plusi, bet parasti tas nevienam nav vajadzīgs, tostarp jums pašiem.

Rokasgrāmata
Izrakt jūsu lietojumprogrammu avota kodus, izveidot rokasgrāmatu, kurā norādīts, kas un kur atrodas un kā tas darbojas, turpat iekļaujiet projekta aprakstu (nosacīts readme.md), lai ātri saprastu, kur atrodas žurnāli un metrikas. Izstrādātājs, kurš ar to darbosies pēc jums, tikai pateiks paldies.

Saprotiet domēnu
Ja jums pieder kāds domēns, centieties sekot līdzi notikumiem. Izklausās banāli, jā, bet ne visi rūpējas par to, lai pakalpojumi būtu vienoti. Un patiesībā strādāt vienā standartā ir jūtami vieglāk.

Tikai reģistrētie lietotāji var piedalīties aptaujā. Pieteikties, lūdzu.