Sattumat ovat satunnaisia, ja todellakin se tapahtui toisella planeetalla...
Haluaisin jakaa kolme menestystarinaa ja epäonnistumistarinaa siitä, kuinka taustakehittäjä työskentelee tiimissä järjestelmänvalvojien kanssa.
Historia ensin.
Web-studio, työntekijöiden määrä voidaan laskea yhdellä kädellä. Tänään olet taittosuunnittelija, huomenna olet backender, ylihuomenna olet järjestelmänvalvoja. Toisaalta voit saada valtavasti kokemusta. Toisaalta osaamisen puute on kaikilla osa-alueilla. Muistan edelleen ensimmäisen työpäivän, olen edelleen vihreä, pomo sanoo: "Avaa kitti", mutta en tiedä mikä se on. Yhteydenpito järjestelmänvalvojien kanssa on suljettu pois, koska olet itse admin. Mietitään tämän tilanteen hyviä ja huonoja puolia.
+ Kaikki valta on sinun käsissäsi.
+ Ei tarvitse pyytää keneltäkään pääsyä palvelimelle.
+ Nopea reaktio kaikkiin suuntiin.
+ Kehittää taitoja hyvin.
+ Sinulla on täydellinen käsitys tuotteen arkkitehtuurista.
– Korkea vastuu.
— Tuotannon katkeamisen vaara.
– On vaikeaa olla hyvä asiantuntija kaikilla aloilla.
Ei kiinnosta, mennään eteenpäin
Toinen tarina.
Iso yritys, iso projekti. Siellä on 5-7 hengen hallintoosasto ja useita kehitysryhmiä. Kun tulet töihin sellaiseen yritykseen, jokainen ylläpitäjä ajattelee, että et tullut tänne työskentelemään tuotteen parissa, vaan rikkomaan jotain. Allekirjoitettu NDA tai haastattelun valinta eivät osoita muuta. Ei, tämä mies tuli tänne likaisilla pienillä käsillään pilatamaan suudelmatuotantomme. Siksi tällaisen henkilön kanssa tarvitset vähintään viestintää; voit ainakin heittää vastauksena tarran. Älä vastaa kysymyksiin projektin arkkitehtuurista. On suositeltavaa olla myöntämättä pääsyä ennen kuin ryhmänjohtaja pyytää. Ja kun hän pyytää, hän antaa sen takaisin jopa vähemmän etuoikeuksilla kuin he pyysivät. Melkein kaikki viestintä tällaisten ylläpitäjien kanssa imeytyy kehitysosaston ja hallintoosaston väliseen mustaan aukkoon. On mahdotonta ratkaista ongelmia nopeasti. Mutta et voi tulla henkilökohtaisesti - järjestelmänvalvojat ovat liian kiireisiä 24/7. (Mitä teet koko ajan?) Joitakin suorituskykyominaisuuksia:
- Keskimääräinen käyttöönottoaika tuotannossa on 4-5 tuntia
- Maksimi käyttöönottoaika tuotannossa 9 tuntia
- Kehittäjälle tuotannossa oleva sovellus on musta laatikko, aivan kuten itse tuotantopalvelin. Kuinka monta niitä on yhteensä?
- Julkaisujen heikko laatu, usein virheitä
- Kehittäjä ei osallistu julkaisuprosessiin
No, mitä odotin, tietysti uusia ihmisiä ei päästetä tuotantoon. No, okei, kun olemme saaneet kärsivällisyyttä, alamme saada muiden luottamuksen. Mutta jostain syystä asiat eivät ole niin yksinkertaisia ylläpitäjien kanssa.
Toimi 1. Järjestelmänvalvoja on näkymätön.
Julkaisupäivä, kehittäjä ja järjestelmänvalvoja eivät kommunikoi. Ylläpitäjällä ei ole kysymyksiä. Mutta ymmärrät myöhemmin miksi. Ylläpitäjä on periaatteellinen henkilö, hänellä ei ole lähettiläitä, ei anna puhelinnumeroaan kenellekään, eikä hänellä ole profiilia sosiaalisissa verkostoissa. Hänestä ei ole edes kuvaa missään, miltä näytät? Istumme vastuullisen johtajan kanssa noin 15 minuuttia hämmentyneenä yrittäen saada yhteyttä tämän Voyager 1:n kanssa, sitten yrityksen sähköpostiin ilmestyy viesti, että hän on lopettanut. Käydäänkö kirjeenvaihdossa? Miksi ei? Kätevää, eikö? No okei, jäähdytään. Prosessi on jo käynnissä, paluuta ei ole. Lue viesti uudelleen. "Minä lopetin". Mitä lopetit? Missä? Mistä minun pitäisi etsiä sinua? Tässä ymmärrät, miksi 4 tuntia vapauttamiseen on normaalia. Saamme kehitysshokin, mutta saamme julkaisun valmiiksi. Ei ole enää halua vapautua.
Laki 2. Ei tuo versio.
Seuraava julkaisu. Kokemuksen saatuaan alamme luoda luetteloita tarvittavista ohjelmistoista ja kirjastoista palvelimelle järjestelmänvalvojille ja ilmoittaa joidenkin versiot. Kuten aina, saamme heikon radiosignaalin, että järjestelmänvalvoja on tehnyt jotain siellä. Regressiotesti alkaa, joka itsessään kestää noin tunnin. Kaikki näyttää toimivan, mutta siinä on yksi kriittinen virhe. Tärkeät toiminnot eivät toimi. Muutaman seuraavan tunnin aikana tanssittiin tamburiinien kanssa, ennustattiin kahvinporoilla ja tarkasteltiin yksityiskohtaisesti jokaista koodia. Ylläpitäjä sanoo tehneensä kaiken. Väärien kehittäjien kirjoittama sovellus ei toimi, mutta palvelin toimii. Onko hänelle kysyttävää? Tunnin päätyttyä saamme järjestelmänvalvojan lähettämään tuotantopalvelimella olevan kirjaston version chattiin ja bingoon – se ei ole se, jota tarvitsemme. Pyydämme järjestelmänvalvojaa asentamaan vaaditun version, mutta vastauksena saamme, että hän ei voi tehdä tätä, koska tämä versio puuttuu käyttöjärjestelmän paketinhallinnasta. Täällä, muistinsa syvennyksistä, johtaja muistaa, että toinen järjestelmänvalvoja oli jo ratkaissut tämän ongelman kokoamalla tarvittavan version käsin. Mutta ei, meidän ei tee tätä. Säännöt kieltävät. Karl, olemme istuneet täällä useita tunteja, mikä aikaraja on?! Saamme uuden shokin ja jotenkin saamme julkaisun loppuun.
Laki 3, lyhyt
Kiireellinen lippu, avaintoiminto ei toimi yhdellä tuotannossa olevista käyttäjistä. Vietämme pari tuntia tuijottaen ja tarkastaen. Kehitysympäristössä kaikki toimii. On selvää, että php-fpm-lokeihin kannattaa tutustua. Projektissa ei tuolloin ollut hirsijärjestelmiä, kuten ELK tai Prometheus. Avaamme lipun hallintoosastolle, jotta he antavat pääsyn palvelimen php-fpm-lokeihin. Tässä sinun on ymmärrettävä, että pyydämme pääsyä syystä, etkö muista mustan aukon ja järjestelmänvalvojien kiireistä 24/7? Jos pyydät heitä katsomaan itse lokit, tämä on tehtävä, jonka prioriteetti on "ei tässä elämässä". Lippu luotiin, saimme välittömän vastauksen hallintoosaston johtajalta: "Sinun ei pitäisi tarvita pääsyä tuotantolokiin, kirjoita ilman virheitä." Verho.
Laki 4 ja sen jälkeen
Keräämme edelleen kymmeniä ongelmia tuotannossa, jotka johtuvat kirjastojen eri versioista, määrittämättömistä ohjelmistoista, valmistautumattomista palvelinkuormituksista ja muista ongelmista. Tietysti on myös koodivirheitä, emme syytä järjestelmänvalvojia kaikista synneistä, mainitsemme vain yhden tyypillisen toiminnon tälle projektille. Meillä oli melko paljon taustatyöntekijöitä, jotka käynnistettiin valvojan kautta, ja joitain skriptejä piti lisätä croniin. Joskus nämä samat työntekijät lopettivat työnsä. Jonopalvelimen kuormitus kasvoi salamannopeasti, ja surulliset käyttäjät katsoivat pyörivää latausohjelmaa. Tällaisten työntekijöiden nopeaan korjaamiseen riitti vain käynnistää ne uudelleen, mutta jälleen kerran, vain järjestelmänvalvoja voi tehdä tämän. Kun tällaista perusoperaatiota suoritettiin, saattoi kulua kokonainen päivä. Tässä on tietysti syytä huomata, että vinojen ohjelmoijien tulisi kirjoittaa työntekijöitä, jotta he eivät kaatuisi, mutta kun ne putoavat, olisi mukava ymmärtää miksi, mikä joskus on mahdotonta tuotantoon pääsyn puutteen vuoksi, tietenkin, ja sen seurauksena kehittäjän lokien puute.
Muutos.
Kaiken tämän kestäneenä melko pitkään, aloimme yhdessä joukkueen kanssa ohjata meitä menestyvämpään suuntaan. Yhteenvetona, mitä ongelmia kohtasimme?
- Laadukkaan viestinnän puute kehittäjien ja hallintoosaston välillä
- Ylläpitäjät, osoittautuu(!), eivät ymmärrä ollenkaan, miten sovellus on rakennettu, mitä riippuvuuksia sillä on ja miten se toimii.
- Kehittäjät eivät ymmärrä tuotantoympäristön toimintaa eivätkä siksi pysty reagoimaan tehokkaasti ongelmiin.
- Käyttöönottoprosessi kestää liian kauan.
- Epävakaat julkaisut.
Mitä me olemme tehneet?
Jokaiselle julkaisulle luotiin julkaisutietoluettelo, joka sisälsi luettelon töistä, jotka on tehtävä palvelimella, jotta seuraava julkaisu toimisi. Lista sisälsi useita osioita, töitä, jotka järjestelmänvalvojan, julkaisusta vastaavan henkilön ja kehittäjän tulisi suorittaa. Kehittäjät saivat ei-root-käyttöoikeudet kaikkiin tuotantopalvelimiin, mikä nopeutti kehitystä yleensä ja ongelmanratkaisua erityisesti. Kehittäjillä on myös käsitys siitä, miten tuotanto toimii, mihin palveluihin se on jaettu, missä ja kuinka paljon jäljennökset maksavat. Osa taistelukuormista on selkiytynyt, mikä epäilemättä vaikuttaa koodin laatuun. Viestintä julkaisuprosessin aikana tapahtui yhden pikaviestien chatissa. Ensinnäkin meillä oli loki kaikista toimista, ja toiseksi kommunikointi tapahtui läheisemmässä ympäristössä. Toimintahistoria on useammin kuin kerran antanut uusille työntekijöille mahdollisuuden ratkaista ongelmia nopeammin. Se on paradoksi, mutta tämä auttoi usein järjestelmänvalvojia itseään. En aio sanoa varmaksi, mutta minusta näyttää siltä, että ylläpitäjät ovat alkaneet ymmärtää paremmin, miten projekti toimii ja miten se on kirjoitettu. Joskus jopa jaoimme joitain yksityiskohtia toisillemme. Keskimääräinen julkaisuaika on lyhennetty tuntiin. Joskus valmistuimme 30-40 minuutissa. Virheiden määrä on vähentynyt merkittävästi, ellei kymmenkertaistunut. Tietenkin muut tekijät vaikuttivat julkaisuajan lyhenemiseen, kuten automaattitestit. Jokaisen julkaisun jälkeen aloimme tehdä retrospektiiviä. Jotta koko tiimillä on käsitys siitä, mitä uutta, mikä on muuttunut ja mitä on poistettu. Valitettavasti järjestelmänvalvojat eivät aina tulleet heidän luokseen, noh, ylläpitäjät ovat kiireisiä... Työtyytyväisyyteni kehittäjänä on epäilemättä lisääntynyt. Kun pystyt ratkaisemaan nopeasti melkein minkä tahansa ongelman, joka kuuluu osaamisalueellesi, tunnet olosi huipulla. Myöhemmin ymmärrän, että otimme jossain määrin käyttöön devops-kulttuuria, ei tietenkään täysin, mutta jopa tuo muodonmuutoksen alku oli vaikuttava.
Tarina kolme
Aloittaa. Yksi järjestelmänvalvoja, pieni kehitysosasto. Saapuessani olen täydellinen nolla, koska... Minulla ei ole pääsyä muualle kuin postista. Kirjoitamme järjestelmänvalvojalle ja pyydämme pääsyä. Lisäksi on tietoa, että hän on tietoinen uudesta työntekijästä ja tarpeesta antaa käyttäjätunnukset/salasanat. Ne antavat pääsyn arkistosta ja VPN:stä. Miksi antaa pääsy wikiin, teamcityyn, rundeskiin? Hyödyttomia asioita henkilölle, joka kutsuttiin kirjoittamaan koko taustaosa. Vain ajan myötä pääsemme käyttämään joitain työkaluja. Saapumiseen suhtauduttiin luonnollisesti epäluottamuksella. Yritän pikkuhiljaa saada tuntumaa projektin infrastruktuurin toimivuudesta chatin ja johtavien kysymysten avulla. Periaatteessa en tunnista mitään. Tuotanto on sama musta laatikko kuin ennenkin. Mutta vielä enemmän, jopa testaukseen käytetyt lavapalvelimet ovat musta laatikko. Emme voi tehdä muuta kuin ottaa Gitin haaran käyttöön siellä. Emme myöskään voi määrittää sovelluksiamme kuten .env-tiedostoja. Pääsyä tällaisiin toimiin ei myönnetä. Sinun täytyy pyytää riviä muutettua testipalvelimen sovelluksesi asetuksissa. (On olemassa teoria, jonka mukaan järjestelmänvalvojien on elintärkeää tuntea olevansa tärkeä projektissa; jos heitä ei pyydetä vaihtamaan rivejä asetuksissa, niitä ei yksinkertaisesti tarvita). No, kuten aina, eikö se ole kätevää? Tämä kyllästyy nopeasti, suoran keskustelun jälkeen järjestelmänvalvojan kanssa saamme selville, että kehittäjät ovat syntyneet kirjoittamaan huonoa koodia, ovat luonnostaan epäpäteviä yksilöitä ja on parempi pitää heidät poissa tuotannosta. Mutta täältä myös testipalvelimista varmuuden vuoksi. Konflikti kärjistyy nopeasti. Ylläpitäjän kanssa ei ole yhteyttä. Tilannetta pahentaa se, että hän on yksin. Seuraava on tyypillinen kuva. Vapauta. Tietyt toiminnot eivät toimi. Kestää kauan selvittää, mitä tapahtuu, keskusteluun heitetään erilaisia ideoita kehittäjiltä, mutta järjestelmänvalvoja yleensä olettaa tällaisessa tilanteessa kehittäjien olevan syyllisiä. Sitten hän kirjoittaa chattiin, odota, korjasin hänet. Kun meitä pyydetään jättämään tarina, jossa kerrotaan ongelmasta, saamme myrkyllisiä tekosyitä. Kuten, älä työnnä nenääsi minne se ei kuulu. Kehittäjien on kirjoitettava koodi. Tilanne, kun projektissa monet kehon liikkeet kulkevat yhden ihmisen kautta ja vain hän pääsee suorittamaan kaikkien tarvitsemat toiminnot, on äärimmäisen surullinen. Tällainen henkilö on kauhea pullonkaula. Jos Devops-ideat pyrkivät lyhentämään markkinoilletuloaikaa, tällaiset ihmiset ovat Devops-ideoiden pahin vihollinen. Valitettavasti verho sulkeutuu täällä.
PS Puhuttuani vähän kehittäjistä vs järjestelmänvalvojia keskusteluissa ihmisten kanssa, tapasin ihmisiä, jotka jakoivat kipuni. Mutta oli myös niitä, jotka sanoivat, että he eivät olleet koskaan kohdanneet mitään tällaista. Yhdessä devops-konferenssissa kysyin Anton Isaninilta (Alfa Bank), kuinka he ratkaisivat pullonkaulaongelman järjestelmänvalvojien muodossa, johon hän sanoi: "Korvasimme ne painikkeilla." Muuten hänen osallistumisensa kanssa. Haluaisin uskoa, että hyviä ylläpitäjiä on paljon enemmän kuin vihollisia. Ja kyllä, alussa oleva kuva on todellinen kirjeenvaihto.
Lähde: www.habr.com