Hei Habr! Esitän huomionne artikkelin käännöksen Kirjailija: Adib Daw
Jos tämä otsikko ei lähetä lievää väristä selkärankaa pitkin, siirry seuraavaan kappaleeseen tai vieraile sivullamme - Haluaisimme puhua.
Kuka me olemme
Olemme 4 pingviinin tiimi, jotka rakastavat koodin kirjoittamista ja laitteiston kanssa työskentelemistä. Vapaa-ajallamme vastaamme yli 7000 3 fyysisen Linux-palvelimen käyttöönotosta, ylläpidosta ja toiminnasta, jotka on jaettu kolmeen eri palvelinkeskukseen eri puolilla Yhdysvaltoja.
Meillä oli myös mahdollisuus tehdä tämä 10 000 kilometrin päässä kohteista, mukavasti omasta toimistostamme, joka sijaitsee lyhyen ajomatkan päässä Välimeren rannalta.
Mittakaavaongelmat
Vaikka startup-yrityksen on järkevää aloittaa infrastruktuurinsa isännöiminen pilvessä suhteellisen alhaisen alkuinvestoinnin vuoksi, me Outbrainissa päätimme käyttää omia palvelimiamme. Teimme tämän, koska pilviinfrastruktuurin kustannukset ylittävät huomattavasti omien datakeskuksissa sijaitsevien laitteiden käyttökustannukset tietylle tasolle kehittämisen jälkeen. Lisäksi palvelimesi tarjoaa korkeimman tason ohjaus- ja vianmääritysominaisuudet.
Kehittyessämme ongelmat ovat aina lähellä. Lisäksi he tulevat yleensä ryhmissä. Palvelinten elinkaaren hallinta vaatii jatkuvaa itsensä kehittämistä voidakseen toimia kunnolla palvelinten määrän nopeassa kasvussa. Palvelinryhmien hallintaohjelmistot konesaleissa käyvät nopeasti raskaaksi. Vikojen havaitsemisesta, vianetsinnästä ja lieventämisestä QoS-standardien täyttämisessä tulee kyseenalaistaa äärimmäisen monipuoliset laitteistot, vaihtelevat työmäärät, päivitysmääräajat ja muut mukavat asiat, joista kukaan ei halua huolehtia.
Hallitse verkkotunnuksiasi
Ratkaisimme monet näistä ongelmista jakoimme palvelimen elinkaaren Outbrainissa sen pääkomponentteihin ja kutsuimme niitä toimialueiksi. Esimerkiksi yksi alue kattaa laitevaatimukset, toinen varaston elinkaareen liittyvän logistiikan ja kolmas kommunikoinnin kenttähenkilöstön kanssa. Toinen koskee laitteiston havaittavuutta, mutta emme kuvaile kaikkia kohtia. Tavoitteenamme oli tutkia ja määritellä verkkotunnuksia niin, että niistä voidaan abstraktia koodin avulla. Kun toimiva abstraktio on kehitetty, se siirretään manuaaliseen prosessiin, joka otetaan käyttöön, testataan ja jalostetaan. Lopuksi toimialue on määritetty integroitumaan muiden toimialueiden kanssa API:iden kautta, mikä muodostaa kokonaisvaltaisen, dynaamisen ja jatkuvasti kehittyvän laitteiston elinkaaren järjestelmän, joka on otettavissa käyttöön, testattavissa ja havaittavissa. Kuten kaikki muutkin tuotantojärjestelmämme.
Tämän lähestymistavan omaksuminen antoi meille mahdollisuuden ratkaista monet ongelmat oikein - luomalla työkaluja ja automaatiota.
Tarvitaan verkkotunnus
Vaikka sähköposti ja laskentataulukot olivat alkuaikoina varteenotettava tapa vastata kysyntään, se ei ollut onnistunut ratkaisu varsinkaan kun palvelimien määrä ja saapuvien pyyntöjen määrä saavuttivat tietyn tason. Saapuvien pyyntöjen organisoimiseksi ja priorisoimiseksi paremmin nopean laajentumisen edessä meidän piti käyttää lippujärjestelmää, joka voisi tarjota:
- Mahdollisuus mukauttaa vain asiaankuuluvien kenttien näkymää (yksinkertainen)
- Avoimet sovellusliittymät (laajennettavissa)
- Tiimimme tuntema (ymmärretty)
- Integrointi olemassa olevien työnkulkujemme kanssa (yhtenäinen)
Koska käytämme Jiraa sprinttien ja sisäisten tehtäviemme hallintaan, päätimme luoda toisen projektin, joka auttaisi asiakkaitamme lähettämään lippuja ja seuraamaan heidän tuloksiaan. Jiran käyttäminen saapuviin pyyntöihin ja sisäisten tehtävien hallintaan antoi meille mahdollisuuden luoda yhden Kanban-levyn, jonka avulla pystyimme katsomaan kaikkia prosesseja kokonaisuutena. Sisäiset "asiakkaamme" näkivät vain laitepyyntöjä, syventämättä lisätehtävien vähemmän merkittäviä yksityiskohtia (kuten työkalujen parantaminen, virheiden korjaaminen).
Kanban-lauta Jirassa
Bonuksena se, että jonot ja prioriteetit olivat nyt kaikkien nähtävissä, mahdollisti sen, että "missä jonossa" tietty pyyntö oli ja mikä sitä edelsi. Näin omistajat pystyivät priorisoimaan omia pyyntöjään ilman, että heidän piti ottaa meihin yhteyttä. Vedä sitä ja se on siinä. Sen avulla pystyimme myös valvomaan ja arvioimaan SLA-sopimuksiamme pyyntötyyppien mukaan Jirassa luotujen mittareiden perusteella.
Laitteen elinkaaren verkkotunnus
Yritä kuvitella kussakin palvelintelineessä käytetyn laitteiston hallinnan monimutkaisuus. Vielä pahempaa on, että monet laitteiston osat (RAM, ROM) voidaan siirtää varastosta palvelinhuoneeseen ja takaisin. Ne myös epäonnistuvat tai ne kirjataan pois ja vaihdetaan ja palautetaan toimittajalle vaihtamista/korjausta varten. Kaikesta tästä on ilmoitettava laitteiston fyysiseen huoltoon osallistuville paikannuspalvelun työntekijöille. Näiden ongelmien ratkaisemiseksi loimme sisäisen työkalun nimeltä Floppy. Hänen tehtävänsä on:
- Viestinnän hallinta kenttähenkilöstön kanssa, kaiken tiedon yhdistäminen;
- "Varasto"-tietojen päivittäminen jokaisen suoritetun ja varmennetun laitehuoltotyön jälkeen.
Varasto puolestaan visualisoidaan Grafanalla, jota käytämme kaikkien mittareiden piirtämiseen. Näin ollen käytämme samaa työkalua varaston visualisointiin ja muihin tuotannon tarpeisiin.
Varastolaitteiden ohjauspaneeli Grafanassa
Takuulla oleville palvelinlaitteille käytämme toista työkalua, jota kutsumme Dispatcheriksi. Hän:
- Kerää järjestelmälokit;
- Luo raportteja toimittajan vaatimassa muodossa;
- Luo pyynnön toimittajalta API:n kautta;
- Vastaanottaa ja tallentaa sovelluksen tunnuksen sen edistymisen seurantaa varten.
Kun reklamaatiomme on hyväksytty (yleensä työaikana), varaosa lähetetään asianmukaiseen datakeskukseen ja henkilökunta hyväksyy sen.
Jenkinsin konsolin lähtö
Viestintäverkkoalue
Pysyäksemme jatkuvasti kasvavaa kapasiteettia vaativan liiketoimintamme nopean kasvun tahdissa jouduimme mukauttamaan tapaamme työskennellä paikallisten datakeskusten teknisten asiantuntijoiden kanssa. Jos aluksi skaalaus tarkoitti uusien palvelimien ostamista, niin konsolidointiprojektin jälkeen (Kubernetesiin siirtymisen perusteella) siitä tuli jotain aivan muuta. Evoluutiomme "telineiden lisäämisestä" "palvelimien uudelleenkäyttöön".
Uuden lähestymistavan käyttö vaati myös uusia työkaluja, jotka mahdollistivat mukavamman vuorovaikutuksen konesalin henkilökunnan kanssa. Näitä työkaluja vaadittiin:
- Yksinkertaisuus;
- Autonomia;
- Tehokkuus;
- Luotettavuus.
Meidän piti sulkea itsemme pois ketjusta ja jäsentää työ siten, että teknikot voisivat työskennellä suoraan palvelinlaitteiden kanssa. Ilman meidän väliintuloamme ja nostamatta säännöllisesti esille kaikkia näitä työmäärää, työaikoja, laitteiden saatavuutta jne. koskevia kysymyksiä.
Tämän saavuttamiseksi asensimme iPadit jokaiseen datakeskukseen. Kun yhteys palvelimeen on muodostettu, tapahtuu seuraavaa:
- Laite vahvistaa, että tämä palvelin todella vaatii työtä;
- Palvelimella käynnissä olevat sovellukset suljetaan (tarvittaessa);
- Slack-kanavalle on lähetetty joukko työohjeita, jotka selittävät tarvittavat vaiheet;
- Työn päätyttyä laite tarkistaa palvelimen lopullisen tilan oikeellisuuden;
- Käynnistää sovellukset uudelleen tarvittaessa.
Lisäksi valmistimme teknikon avuksi Slack-botin. Monien ominaisuuksien ansiosta (laajensimme toiminnallisuutta jatkuvasti) botti helpotti heidän työtään ja helpotti elämäämme paljon. Tällä tavalla optimoimme suurimman osan palvelimien uudelleenkäyttö- ja ylläpitoprosessista ja eliminoimme itsemme työnkulusta.
iPad yhdessä palvelinkeskuksistamme
Laitteiston verkkotunnus
Palvelinkeskusinfrastruktuurimme luotettava skaalaaminen edellyttää hyvää näkyvyyttä jokaiseen komponenttiin, esimerkiksi:
- Laitteistovian havaitseminen
- Palvelimen tilat (aktiivinen, isännöity, zombie jne.)
- Virrankulutus
- Laiteversio
- Analyysi koko tälle liiketoiminnalle
Ratkaisumme avulla voimme tehdä päätöksiä siitä, miten, mistä ja milloin ostaa laitteita, joskus jopa ennen kuin niitä todella tarvitaan. Myös eri laitteiden kuormitustasoa määrittämällä pystyimme parantamaan resurssien allokointia. Erityisesti energiankulutus. Voimme nyt tehdä tietoisia päätöksiä palvelimen sijoittamisesta ennen kuin se asennetaan telineeseen ja liitetään virtalähteeseen, koko sen elinkaaren ajan ja siihen asti, kun se lopulta poistetaan käytöstä.
Energy Dashboard Grafanassa
Ja sitten COVID-19 ilmestyi...
Tiimimme luo teknologioita, jotka antavat mediayrityksille ja julkaisijoille mahdollisuuden verkossa auttaa vierailijoita löytämään heille mahdollisesti kiinnostavaa sisältöä, tuotteita ja palveluita. Infrastruktuurimme on suunniteltu palvelemaan liikennettä, joka syntyy, kun jännittäviä uutisia julkaistaan.
COVID-19:ää ympäröivä intensiivinen mediakuva yhdessä liikenteen kasvun kanssa tarkoitti, että meidän oli kiireesti opittava selviytymään näistä paineista. Lisäksi kaikki tämä piti tehdä globaalin kriisin aikana, jolloin toimitusketjut katkesivat ja suurin osa henkilökunnasta oli kotona.
Mutta kuten jo sanoimme, mallimme olettaa jo seuraavaa:
- Palvelinkeskustemme laitteet ovat suurimmaksi osaksi fyysisesti ulottumattomissamme;
- Teemme lähes kaikki fyysiset työt etänä;
- Työtä tehdään asynkronisesti, itsenäisesti ja suuressa mittakaavassa;
- Vastaamme laitteiden kysyntään "build from parts" -menetelmällä uusien laitteiden ostamisen sijaan;
- Meillä on varasto, jonka avulla voimme luoda jotain uutta, ei vain tehdä rutiinikorjauksia.
Näin ollen globaalit rajoitukset, jotka estivät monien yritysten fyysisen pääsyn konesaleihinsa, eivät vaikuttaneet meihin juurikaan.Ja varaosien ja palvelimien osalta, kyllä, yritimme varmistaa laitteiden vakaan toiminnan. Mutta tämä tehtiin tarkoituksena estää mahdolliset tapaukset, kun yhtäkkiä käy ilmi, että jokin laitteisto ei ole saatavilla. Varmistimme, että reservimme täyttyvät pyrkimättä vastaamaan nykyiseen kysyntään.
Yhteenvetona haluan sanoa, että lähestymistapamme konesaliteollisuudessa työskentelemiseen todistaa, että hyvän koodisuunnittelun periaatteita on mahdollista soveltaa konesalin fyysiseen hallintaan. Ja ehkä löydät sen mielenkiintoiseksi.
alkuperäinen:
Lähde: will.com