Bank projeyên xwe ji gelek peymankaran re vedigire. "External" kodê dinivîsin, dûv re encaman bi rengek ne pir hêsan vediguhezînin. Bi taybetî, pêvajo bi vî rengî xuya bû: wan projeyek ku bi wan re ceribandinên fonksiyonel derbas kir radestî wan kirin, û dûv re ji bo yekbûn, barkirin, û hwd di hundurê perimetra bankê de hate ceribandin. Pir caran hate kifş kirin ku ceribandin bi ser neketin. Dûv re her tişt vegeriya pêşdebirê derveyî. Wekî ku hûn dikarin texmîn bikin, ev tê wateya demên dirêj ên ji bo rastkirina xeletiyan.
Bankê biryar da ku mimkun û pêdivî ye ku tevahiya boriyê di bin baskê xwe de bikişîne, ji pabendbûnê heta berdanê. Ji ber ku her tişt yekreng û di bin kontrola tîmên berpirsiyar ên hilberê di bankê de ye. Ango, mîna ku peykerê derve bi tenê li cîhek li jûreya din a ofîsê dixebitî. Li ser pişka pargîdanî. Ev devokek asayî ye.
Sec ji ku hat? Ewlekariya bankê daxwazên mezin daniye ser ka peykerek derveyî çawa dikare di beşa torê de bixebite, çi gihîştina kesek heye, çawa û kî bi kodê re dixebite. Tenê ev e ku IB hîna nizanibû ku dema ku peymankar li derve dixebitin, çend standardên bankingê têne şopandin. Û dûv re di nav du rojan de her kes hewce dike ku dest bi çavdêriya wan bike.
Peyxama sade ya ku peyker xwedan koda hilberê bi tevahî bû, berê cîhana wan berovajî kiribû.
Di vê gavê de, çîroka DevSecOps dest pê kir, ku ez dixwazim ji we re vebêjim.
Bankê ji vê rewşê çi encamên pratîkî derxist?
Li ser wê yekê ku her tişt bi awayekî şaş tê kirin, gelek nîqaş hatin kirin. Pêşdebiran got ku ewlehî tenê mijûlî hewldana astengkirina pêşveçûnê ye, û ew, mîna nobedaran, bêyî ku bifikirin hewl didin ku qedexe bikin. Wekî din, pisporên ewlehiyê di navbera hilbijartina di navbera nêrînan de dudil bûn: "pêşdebir di çerxa me de qelsiyan diafirînin" û "pêşdebir qelsiyan naafirînin, lê ew bi xwe ne." Ger ne ji daxwazên bazarê yên nû û derketina paradîgmaya DevSecOps nebûna, nakokî dê demek dirêj berdewam bikira. Mimkun bû ku were ravekirin ku ev bixweberkirina pêvajoyên ku hewcedariyên ewlehiya agahdariyê "ji derveyî qutiyê" dihesibîne dê ji her kesî re bibe alîkar ku kêfxweş bimîne. Di vê wateyê de ku qaîdeyên tavilê têne nivîsandin û di dema lîstikê de nayên guheztin (ewlehiya agahdariyê dê tiştek ji nedîtî ve neyê qedexe kirin), û pêşdebiran ewlehiya agahdariyê ji her tiştê ku diqewime agahdar dikin (ewlekariya agahdariyê ji nişka ve bi tiştek re rû bi rû nabe) . Her tîm jî ji ewlehiya dawîn berpirsiyar e, û ne hin birayên mezin ên abstrakt.
- Ji ber ku karmendên derveyî berê xwedan kod û hejmarek pergalên hundurîn in, belkî gengaz e ku hewcedariya "pêşveçûn bi tevahî li ser binesaziya bankê were kirin" ji belgeyan were derxistin.
- Ji aliyê din ve, divê em kontrola li ser tiştên ku diqewimin xurt bikin.
- Lihevhatin afirandina tîmên cross-fonksîyonel bû, ku karmend ji nêz ve bi mirovên derveyî re dixebitin. Di vê rewşê de, hûn hewce ne ku pê ewle bin ku tîm li ser amûrên li ser serverên bankê dixebite. Ji serî heta dawiyê.
Ango, peymankar dikarin werin destûr kirin, lê pêdivî ye ku ji wan re beşên cûda werin dayîn. Ji bo ku ew cûreyek enfeksiyonê ji derve nexin nav binesaziya bankê û ji bo ku ew ji ya pêwîst zêdetir nebînin. Welê, da ku kiryarên wan têne tomar kirin. DLP ji bo parastina li dijî leaksiyonê, ev hemî tê de bû.
Di prensîbê de, hemî bank zû an dereng têne vê yekê. Li vir em ketin rê û em li ser hewcedariyên hawîrdorên weha ku "derveyî" lê dixebitin li hev kirin. Rêzeya herî zêde amûrên kontrolkirina gihîştinê, amûrên kontrolkirina qelsbûnê, analîzên dijî-vîrusê yên li ser çerx, meclîs û ceribandinan xuya bûn. Ji vê re DevSecOps tê gotin.
Ji nişkê ve eşkere bû ku heke berî ewlehiya bankingê ya DevSecOps ti kontrolek li ser tiştên ku ji hêla pêşdebiran diqewime tune bû, wê hingê di paradîgmaya nû de ewlehî bi heman awayê bûyerên asayî yên li ser binesaziyê tê kontrol kirin. Tenê niha li ser meclîsan, kontrolkirina pirtûkxaneyan û hwd hişyarî hene.
Tiştê ku dimîne ev e ku tîmên veguhezînin modela nû. Welê, binesaziyê çêbikin. Lê ev tifing in, ew mîna xêzkirina kewekê ye. Bi rastî, me di binesaziyê de alîkarî kir, û wê demê pêvajoyên pêşveçûnê diguherin.
Çi hatiye guhertin
Me biryar da ku em wê bi gavên piçûk pêk bînin, ji ber ku me fêm kir ku dê gelek pêvajo ji hev bikevin, û dibe ku gelek "derveyî" nikaribin li ber şert û mercên nû yên xebatê di bin çavdêriya her kesî de li ber xwe bidin.
Pêşîn, me tîmên pir-fonksîyonel afirandin û fêr bûn ku me li gorî hewcedariyên nû projeyan organîze bikin. Di wateya rêxistinî de me behsa çi pêvajoyan kir. Di encamê de şemaya lûleya meclîsê bi hemû berpirsyaran re bû.
- IC: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
- CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
- Îmtîhan: Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Navenda Performansê, MF UFT, Ataccama.
- Pêşkêşî (rapor, ragihandin): Grafana, Kibana, Jira, Confluence, RocketChat.
- operasyonên (xebitandin, rêvebirin): Ansible, Zabbix, Prometheus, Elastic + Logstash, Rêvebirê Karûbarê MF, Jira, Confluence, Projeya MS.
Pişka hilbijartî:
- Bingeha Zanînê - Tevliheviya Atlassian;
- Task tracker - Atlassian Jira;
- Depoya Artifact - "Nexus";
- Pergala yekbûna domdar - "Gitlab CI";
- Pergala analîza domdar - "SonarQube";
- Pergala analîzkirina ewlehiya serîlêdanê - "Micro Focus Fortify";
- Pergala ragihandinê - "GitLab Mattermost";
- Pergala rêveberiya vesazkirinê - "Ansible";
- Pergala çavdêriyê - "ELK", "TICK Stack" ("InfluxData").
Wan dest bi afirandina tîmek ku dê amade be ku peymankaran bikişîne hundurê xwe. Têgihîştinek heye ku çend tiştên girîng hene:
- Divê her tişt yekgirtî be, bi kêmanî dema ku kodê veguhezîne. Ji ber ku bi qasî ku gelek pêvajoyên pêşveçûnê yên cuda yên bi taybetmendiyên xwe hene, peymanker hebûn. Pêwîst bû ku her kes bi qasî yek, lê bi vebijarkan bi cih bibe.
- Gelek peymankar hene, û çêkirina binesaziyê bi destan ne guncaw e. Pêdivî ye ku her peywirek nû pir zû dest pê bike - ango, mînak divê hema tavilê were bicîh kirin da ku pêşdebiran komek çareseriyan hebin da ku xeta boriyê xwe birêve bibin.
Ji bo avêtina gava yekem, hewce bû ku were fêm kirin ku çi tê kirin. Û diviyabû me diyar bikira ka emê çawa biçin wir. Me bi alîkariya xêzkirina mîmariya çareseriya armancê hem di binesaziyê û hem jî di xweseriya CI/CD de dest pê kir. Paşê me dest bi komkirina vê konveyerê kir. Pêdiviya me bi binesaziyek hebû, ji bo her kesî yek, ku li wir heman veguhezkar lê bimeşin. Me bi hesaban vebijark pêşkêş kir, bank fikirî, paşê biryar da ku dê çi û bi çi fonan were çêkirin.
Dû re afirandina çerxerê ye - sazkirina nermalavê, veavakirin. Pêşxistina skrîptan ji bo danîn û rêvebirina binesaziyê. Dûv re derbasbûna ji bo piştgiriya veguheztinê tê.
Me biryar da ku em her tiştî li ser pîlotê biceribînin. Balkêş e, ku di dema pîlotkirinê de, di bankê de ji bo cara yekem stûnek diyar bû. Di nav tiştên din de, firoşkarek navxweyî ya yek ji çareseriyan ji bo pîlotê ji bo destpêkirina bilez hate pêşkêş kirin. Ewlekariyê dema ku wî pîlotî dikir ew nas kir, û ew bandorek nebîrkirî hişt. Dema ku me biryar da ku em biguhezînin, bextewar, qata binesaziyê bi çareseriyek Nutanix, ku berê di bankê de bû, hate guheztin. Wekî din, berî wê ew ji bo VDI bû, lê me ew ji bo karûbarên binesaziyê ji nû ve bikar anî. Di cildên piçûk de ew di aboriyê de cîh nedigirt, lê di cildên mezin de ew ji bo pêşkeftin û ceribandinê bû hawîrdorek hêja.
Yên mayî ji her kesî re kêm-zêde nas e. Amûrên otomasyonê yên li Ansible hatin bikar anîn, û pisporên ewlehiyê ji nêz ve bi wan re xebitîn. Stack Atlassin berî projeyê ji hêla bankê ve hatî bikar anîn. Amûrên ewlehiyê yên Fortinet - ew ji hêla mirovên ewlehiyê bixwe ve hatî pêşniyar kirin. Çarçoveya ceribandinê ji hêla bankê ve hate afirandin, pirs nehat pirsîn. Pergala depoyê pirsan derdixist; Diviya bû ku ez jê re bimeşim.
Kontrayan stelek nû hat dayîn. Wan dem da me ku em wê ji bo GitlabCI ji nû ve binivîsin, û Jira koçî beşa bankingê bikin, û hwd.
gav bi gav
Stage 1. Pêşîn, me çareseriyek ji firoşkarek navxweyî bikar anî, hilber bi beşa torê ya DSO-ya nû hatî afirandin ve hate girêdan. Platform ji bo dema radestkirina xwe, nermbûna pîvanê û îmkana otomasyona tevahî hate hilbijartin. Testên hatine kirin:
- Ihtîmala rêveberiya maqûl û bi tevahî otomatîk a binesaziya platforma virtualbûnê (tor, binepergala dîskê, binepergala çavkaniyên hesabkirinê).
- Otomatîzekirina rêveberiya çerxa jiyanê ya makîneya virtual (şablon, wêne, paşvekişandin).
Piştî sazkirinê û veavakirina bingehîn a platformê, ew wekî xala danîna bine pergalên qonaxa duyemîn (Amûrên DSO, nexşeyên pêşkeftina pergalên firotanê) hate bikar anîn. Komên pêdivî yên boriyan hatin afirandin - afirandin, jêbirin, guheztin, paşvekişandina makîneyên virtual. Ev xetên boriyan weke qonaxa yekem a pêvajoya bicihkirinê hatin bikaranîn.
Encam ev e ku alavên peydakirî ji bo performans û tolerasyona xeletiyê hewcedariyên bankê nagirin. DIT a bankê biryar da ku li ser bingeha pakêta nermalava Nutanix kompleksek ava bike.
Stage 2. Me stûna ku hatî destnîşan kirin hilda, û ji bo hemî bine-pergalan skrîptên sazkirinê û paş-vesazkirinê yên otomatîkî nivîsandin da ku her tişt bi lez û bez ji pîlotê veguhezîne qada armancê. Hemî pergal di veavakirinek xelet-tolerant de hatine bicîh kirin (ku ev kapasîteyê ji hêla polîtîkayên lîsansê yên firoşkar ve ne sînorkirî ye) û bi metrîk û bine pergalên berhevkirina bûyerê ve hatine girêdan. IB lihevhatina bi daxwazên wê re analîz kir û ronahiya kesk da.
Stage 3. Koçkirina hemî binpergalan û mîhengên wan berbi PAC-a nû. Nivîsarên otomasyona binesaziyê ji nû ve hatin nivîsandin, û koçkirina binepergalên DSO di modek bi tevahî otomatîk de qediya. Rêzikên pêşkeftina IP-ê ji hêla lûleyên tîmên pêşkeftinê ve ji nû ve hatin çêkirin.
Stage 4. Otomasyona sazkirina nermalava serîlêdanê. Van peywiran ji hêla tîmê tîmên nû ve hatine danîn.
Stage 5. Kedmêjî.
Gihîştina dûr
Tîmên pêşkeftinê di xebata bi çerxê de nermbûna herî zêde xwestin, û hewcedariya gihîştina dûr a ji laptopên kesane di destpêka projeyê de hate bilind kirin. Bank berê xwedan gihîştina dûr bû, lê ew ji bo pêşdebiran ne maqûl bû. Rastî ev e ku pîlan girêdana bikarhêner bi VDI-ya parastî ve bikar anî. Ev ji bo kesên ku tenê li cîhê xebata xwe hewceyê nameyê û pakêtek nivîsgehê bûn maqûl bû. Pêşdebir dê hewceyê xerîdarên giran, performansa bilind, bi gelek çavkaniyan bin. Û bê guman, ew neçar bûn ku statîk bin, ji ber ku windakirina danişîna bikarhêner ji bo kesên ku bi VStudio (mînakek) an SDK-ya din re dixebitin nayê qebûl kirin. Organîzekirina hejmareke mezin ji VDI-yên statîk ên stûr ji bo hemî tîmên pêşkeftinê lêçûna çareseriya VDI ya heyî pir zêde kir.
Me biryar da ku em rasterast li ser çavkaniyên beşa pêşkeftinê li ser gihîştina dûr bixebitin. Jira, Wiki, Gitlab, Nexus, bengehên çêkirin û ceribandinê, binesaziya virtual. Gardiyanên ewlehiyê daxwaz kirin ku gihîştin tenê di şertên jêrîn de bêne peyda kirin:
- Bikaranîna teknolojiyên ku berê di bankê de hene.
- Pêdivî ye ku binesaziya kontrolkerên domainê yên heyî yên ku tomarên tiştên hesabê hilberîner hilînin bikar neynin.
- Pêdivî ye ku gihîştin tenê bi wan çavkaniyên ku ji hêla tîmek taybetî ve têne xwestin ve were sînorkirin (da ku tîmek hilberek nikaribe bigihîje çavkaniyên tîmek din).
- Kontrola herî zêde ya li ser RBAC di pergalan de.
Wekî encamek, ji bo vê beşê domainek veqetandî hate afirandin. Vê domainê hemî çavkaniyên beşa pêşkeftinê, hem pêbaweriyên bikarhêner û hem jî binesaziyê dihewîne. Çîroka jiyanê ya tomarên di vê domainê de bi karanîna IdM-ya ku di bankê de heye tê rêvebirin.
Gihîştina ji dûr a rasterast li ser bingeha amûrên heyî yên bankê hate organîze kirin. Kontrola gihîştinê di komên AD-ê de hate dabeş kirin, ku qaîdeyên li ser çarçoweyan bi wan re têkildar in (komek hilber = yek komek rêzik).
Rêveberiya Şablonê VM
Leza çêkirina meclîs û ceribandinê yek ji KPI-yên sereke ye ku ji hêla serokê yekîneya pêşkeftinê ve hatî destnîşan kirin, ji ber ku leza amadekirina jîngehê rasterast bandorê li ser dema darvekirina giştî ya boriyê dike. Ji bo amadekirina wêneyên bingehîn ên VM du vebijark hatin girtin. Ya yekem mezinahiyên wêneya hindiktirîn e, ji bo hemî hilberên pergalê xwerû, herî zêde lihevhatina bi polîtîkayên bankê yên di derbarê mîhengan de ye. Ya duyemîn wêneya bingehîn e, ku tê de POPPO-ya giran a hatî saz kirin, dema sazkirina wê dikare pir bandorê li leza darvekirina boriyê bike.
Pêdiviyên binesaziyê û ewlehiyê jî di dema pêşkeftinê de hatin girtin - nûvekirina wêneyan (patch, hwd.), entegrasyona bi SIEM-ê, mîhengên ewlehiyê li gorî standardên bankê.
Wekî encamek, biryar hate girtin ku wêneyên hindiktirîn bikar bînin da ku lêçûna nûvekirina wan kêm bikin. Nûvekirina OS-ya bingehîn ji guheztina her wêneyê ji bo guhertoyên nû yên POPPO pir hêsantir e.
Li ser bingeha encaman, navnîşek ji hindiktirîn koma pergalên xebitandinê yên hewce hate çêkirin, ku nûvekirina wê ji hêla tîmê operasyonê ve tête kirin, û nivîsarên ji boriyê bi tevahî ji nûvekirina nermalavê berpirsiyar in, û ger hewce be, guhertoyê biguhezînin. ya nermalava sazkirî - tenê etîketa pêwîst veguhezîne boriyê. Erê, ev hewce dike ku tîmê hilberê devops xwedan senaryoyên bicîhkirina tevlihevtir be, lê ew dema xebitandinê ya ku ji bo piştgirîkirina wêneyên bingehîn hewce dike pir kêm dike, ku wekî din ji bo domandina sed wêneyên bingehîn ên VM hewce dike.
Gihîştina Înternetê
Astengiyek din a ewlehiya bankingê gihîştina çavkaniyên Înternetê ji hawîrdora pêşkeftinê bû. Wekî din, ev gihîştin dikare li du kategoriyan were dabeş kirin:
- Gihîştina binesaziyê.
- Gihîştina pêşdebiran.
Gihîştina binesaziyê bi prokskirina depoyên derveyî bi Nexus re hate organîze kirin. Ango gihandina rasterast ji makîneyên virtual nehat peyda kirin. Vê yekê gengaz kir ku meriv bi ewlehiya agahdariyê re bigihîje lihevkirinek, ku bi rengekî kategorî li dijî peydakirina her gihîştina cîhana derve ji beşa pêşkeftinê bû.
Pêşdebiran ji ber sedemên diyar (stackoverflow) hewceyê gihîştina Înternetê bûn. Û her çend hemî fermanan, wekî ku li jor hatî behs kirin, gihîştina ji dûr ve li çerxê hebûn, gava ku hûn nekarin ctrl+v ji cîhê xebata pêşdebiran a li bankê di IDE-yê de bikin, her gav ne hêsan e.
Lihevkirinek bi IS re hate kirin ku di destpêkê de, di qonaxa ceribandinê de, dê gihîştin bi riya nûnerek bankî li ser bingeha navnîşek spî were peyda kirin. Piştî qedandina projeyê, dê gihîştin navnîşa reş were veguheztin. Tabloyên gihîştinê yên mezin hatin amadekirin, ku çavkanî û depoyên sereke yên ku di destpêka projeyê de pêdiviya wan bi wan hebû destnîşan kirin. Koordînasyona van gihîştinan demek maqûl girt, ku ev gengaz kir ku di veguheztina zûtirîn gengaz a navnîşên reş de israr bike.
Encam
Proje salek hindiktir qediya. Pir ecêb e, hemî peyker bi wextê xwe veguheztin stûna nû û ji ber otomasyona nû kes neçû. IB ecele nake ku bertekên erênî parve bike, lê gilî jî nake, ji vê yekê em dikarin encam bidin ku ew jê hez dikin. Pevçûn kêm bûne ji ber ku ewlehiya agahdariyê dîsa di bin kontrolê de hîs dike, lê di pêvajoyên pêşkeftinê de mudaxele nake. Tîman bêtir berpirsiyarî hatin dayîn, û helwesta giştî ya li hember ewlehiya agahdarî çêtir bû. Bankê fêm kir ku veguheztina DevSecOps hema hema neçar bû, û ew, bi dîtina min, bi awayê herî nerm û rast kir.
Alexander Shubin, mîmarê pergalê.
Source: www.habr.com