Kirjoitin jo Habrén julkaisuissa kokemuksestani kumppanuuksien rakentamisesta tiimini kanssa ( kertoo kuinka tehdä kumppanuussopimus uuden yrityksen perustamisen yhteydessä, jotta yritys ei hajoa). Ja nyt haluaisin puhua kumppanuuksien rakentamisesta asiakkaiden kanssa, koska ilman heitä ei ole mitään hajoavaa. Toivon, että tästä artikkelista on hyötyä aloittaville yrityksille, jotka alkavat myydä tuotteitaan suurille yrityksille.
Tällä hetkellä johdan startuppia nimeltä MONQ Digital lab, jossa kehitämme tiimini kanssa tuotetta yrityksen IT-tuki- ja toimintaprosessien automatisointiin. Markkinoille tulo ei ole helppo tehtävä ja aloitimme pienellä läksyllä, käytiin läpi markkinaasiantuntijat, yhteistyökumppanimme ja toteutimme markkinoiden segmentoinnin. Pääkysymys oli ymmärtää "kenen kivut voimme parhaiten parantaa?"
Pankit pääsivät TOP 3 -segmenttien joukkoon. Ja tietysti listan ensimmäisinä olivat Tinkoff ja Sberbank. Kun vierailimme pankkimarkkinoiden asiantuntijoiden luona, he sanoivat: esittele tuotteesi siellä, niin tie pankkimarkkinoille aukeaa. Yritimme päästä sisään sekä sinne että sinne, mutta epäonnistuminen odotti meitä Sberbankissa, ja Tinkoffin kaverit osoittautuivat paljon avoimemmiksi tuottavalle kommunikaatiolle venäläisten startup-yritysten kanssa (ehkä johtui siitä, että Sber tuolloin lähes miljardi länsimaisista kilpailijoistamme). Kuukauden sisällä aloitimme pilottiprojektin. Kuinka se tapahtui, lue.
Olemme käsitelleet toiminta- ja seurantakysymyksiä monta vuotta, nyt otamme tuotettamme käyttöön julkisella sektorilla, vakuutusalalla, pankeissa, teleyhtiöissä, yksi toteutus oli lentoyhtiön kanssa (ennen projektia emme edes tehneet luulen, että lentoliikenne oli niin IT-riippuvainen toimiala, ja nyt todella toivomme, COVID-viruksesta huolimatta, että yritys nousee esiin ja lähtee nousuun).
Valmistamamme tuote kuuluu yritysohjelmistoihin, AIOps (Artificial Intelligence for IT Operations, eli ITOps) -segmenttiin. Tällaisten järjestelmien käyttöönoton päätavoitteet prosessin kypsyysasteen kasvaessa yrityksessä:
- Sammuta tulipalot: tunnista viat, puhdista hälytysvirta roskista, anna tehtäviä ja vaaratilanteita vastuullisille;
- Lisää IT-palvelun tehokkuutta: lyhennä tapausten ratkaisemiseen kuluvaa aikaa, osoita vikojen syyt, lisää IT-tilan läpinäkyvyyttä;
- Lisää liiketoiminnan tehokkuutta: vähennä käsityön määrää, vähennä riskejä, lisää asiakasuskollisuutta.
Kokemuksemme mukaan pankeilla on seuraavat seurannan "kivut" kaikille suurille IT-infrastruktuureille:
- "kuka tietää mitä": teknisiä osastoja on monia, lähes jokaisella on vähintään yksi valvontajärjestelmä, ja useimmilla on useampi kuin yksi;
- "hyttysparvi" hälytyksiä: jokainen järjestelmä tuottaa satoja ja pommittaa niillä kaikkia vastuullisia (joskus myös osastojen välillä). Jokaisen ilmoituksen valvonnan painopisteen jatkuva pitäminen on vaikeaa, niiden kiireellisyys ja tärkeys tasoittuvat suuren määrän vuoksi;
- suuret pankit – sektorin johtajat eivät halua vain jatkuvasti valvoa järjestelmiään, tietää missä on vikoja, vaan myös tekoälyn todellista taikuutta – saada järjestelmät valvomaan itseään, ennakoimaan ja korjaamaan itseään.
Kun tulimme ensimmäiseen tapaamiseen Tinkoffissa, meille kerrottiin heti, että heillä ei ollut mitään ongelmia seurannan kanssa eikä mikään satuttanut heitä, ja pääkysymys oli: "Mitä voimme tarjota niille, jotka voivat jo hyvin?"
Keskustelu oli pitkä, keskustelimme kuinka heidän mikropalvelut rakennetaan, miten osastot toimivat, mitkä infrastruktuuriongelmat ovat herkempiä, mitkä ovat vähemmän herkkiä käyttäjille, missä ovat "sokeat kulmat" ja mitkä ovat niiden tavoitteet ja SLA-sopimukset.
Muuten, pankin SLA-sopimukset ovat todella vaikuttavia. Esimerkiksi prioriteetin XNUMX verkon saatavuushäiriön ratkaiseminen voi kestää vain muutaman minuutin. Virheiden ja seisokkien kustannukset ovat tietysti vaikuttavat.
Tämän seurauksena tunnistimme useita yhteistyöalueita:
- ensimmäinen vaihe on sateenvarjovalvonta, joka nopeuttaa tapausten ratkaisemista
- toinen vaihe on prosessiautomaatio riskien ja IT-osaston skaalauksen kustannusten vähentämiseksi.
Useita ”valkoisia pisteitä” voitiin maalata hälytysten kirkkailla väreillä vain käsittelemällä tietoja useista valvontajärjestelmistä, koska mittareita oli mahdotonta ottaa suoraan, oli myös tarpeen keskittää tiedot eri valvontajärjestelmistä ”yhdelle näytölle”, jotta ymmärtääkseen kokonaiskuvan tapahtuneesta. "Sateenvarjot" sopivat tähän tehtävään ja täytimme nämä vaatimukset silloin.
Meidän mielestämme erittäin tärkeä asia asiakassuhteissa on rehellisyys. Ensimmäisen keskustelun ja lisenssin hintalaskelman jälkeen todettiin, että koska hinta on niin alhainen, kannattaa ehkä ostaa lisenssi heti (verrattuna Dynatrace Klyuch-Astromiin yllä olevasta vihreää pankkia käsittelevästä artikkelista, meidän Lisenssi ei maksa kolmannesta miljardista, vaan 12 tuhatta ruplaa kuukaudessa 1 gigatavua kohti, Sberille se maksaisi useita kertoja halvempaa). Mutta kerroimme heille heti, mitä meillä on ja mitä ei. Ehkä suuren integraattorin myyntiedustaja voisi sanoa "kyllä, voimme tehdä kaiken, tietysti ostaa lisenssimme", mutta päätimme nostaa kaikki korttimme pöydälle. Julkaisuhetkellä laatikossamme ei ollut integraatiota Prometheuksen kanssa, ja uusi versio automaatioalijärjestelmällä oli ilmestymässä, mutta emme ole vielä toimittaneet sitä asiakkaille.
Pilottiprojekti alkoi, sen rajat määriteltiin ja meille annettiin 2 kuukautta aikaa. Päätehtävät olivat:
- valmistele uusi versio alustasta ja ota se käyttöön pankin infrastruktuurissa
- yhdistä 2 valvontajärjestelmää (Zabbix ja Prometheus);
- lähettää ilmoituksia Slackin vastuuhenkilöille ja tekstiviestillä;
- ajaa automaattisia korjausskriptejä.
Pilottiprojektin ensimmäinen kuukausi meni alustan uuden version valmisteluun supernopeassa tilassa pilottiprojektin tarpeisiin. Uusi versio sisältää välittömästi integroinnin Prometheuksen kanssa ja automaattisen parantamisen. Kehitystiimimme ansiosta he eivät nukkuneet useaan yöhön, vaan vapauttivat lupauksensa ilman, että menivät muiden aiemmin tehtyjen sitoumusten määräaikaan.
Kun asensimme pilottia, törmäsimme uuteen ongelmaan, joka saattoi sulkea projektin etuajassa: hälytyksiä lähettämiseen pikaviestintälaitteille ja tekstiviestien kautta tarvitsimme saapuvat ja lähtevät yhteydet Microsoft Azure -palvelimiin (silloin käytimme tätä alustaa lähettääksesi hälytyksiä Slackiin) ja ulkoisen lähetyspalvelun tekstiviestin. Mutta tässä projektissa turvallisuus oli erityisen tärkeä painopiste. Pankin politiikan mukaisesti tällaisia ”reikiä” ei saa missään olosuhteissa avata. Kaiken piti toimia suljetussa kierrossa. Meille tarjottiin omien sisäisten palvelujemme API-liittymää, joka lähettää hälytyksiä Slackiin ja tekstiviestillä, mutta meillä ei ollut mahdollisuutta liittää tällaisia palveluita suoraan laatikosta.
Keskusteluilta kehitystiimin kanssa päättyi onnistuneeseen ratkaisun etsintään. Selvitettyämme ruuhkaa löysimme yhden tehtävän, johon meillä ei koskaan ollut tarpeeksi aikaa ja prioriteettia - luoda laajennusjärjestelmä, jotta toteutusryhmät tai asiakas voisi kirjoittaa itse lisäosia, mikä laajentaa alustan ominaisuuksia.
Mutta meillä oli tasan kuukausi jäljellä, jonka aikana meidän piti asentaa kaikki, konfiguroida ja ottaa käyttöön automaatio.
Pääarkkitehtimme Sergein mukaan plug-in-järjestelmän käyttöönotto kestää vähintään kuukauden.
Meillä ei ollut aikaa...
Oli vain yksi ratkaisu - mene asiakkaan luo ja kerro kaikki niin kuin se on. Keskustelkaa yhdessä määräajan siirtymisestä. Ja se toimi. Saimme 2 viikkoa lisäaikaa. Heillä oli myös omat määräaikansa ja sisäiset velvoitteensa näyttää tuloksia, mutta heillä oli 2 varaviikkoa. Lopulta laitoimme kaiken linjalle. Oli mahdotonta sotkea. Rehellisyys ja kumppanuus kannatti jälleen.
Pilotin tuloksena saatiin useita tärkeitä teknisiä tuloksia ja johtopäätöksiä:
Testasimme uutta toimintoa hälytysten käsittelyyn
Käyttöön otettu järjestelmä alkoi vastaanottaa Prometheuksen hälytyksiä oikein ja ryhmitellä ne. Hälytykset ongelmasta Prometheus-asiakkaalta lensivät 30 sekunnin välein (ajan mukaan ryhmittely ei ole käytössä), ja mietimme, olisiko mahdollista ryhmitellä ne itse "sateenvarjossa". Kävi ilmi, että se on mahdollista - hälytysten käsittelyn asettaminen alustalle toteutetaan komentosarjalla. Tämä mahdollistaa lähes minkä tahansa logiikan toteuttamisen niiden käsittelyyn. Olemme jo toteuttaneet alustassa vakiologiikkaa mallien muodossa - jos et halua keksiä jotain omaa, voit käyttää valmiita.
"Synteettinen laukaisu" käyttöliittymä. Kytkettyjen valvontajärjestelmien hälytysten käsittelyn määrittäminen
Rakensi järjestelmän "terveyden" tilan
Hälytysten perusteella luotiin valvontatapahtumia, jotka vaikuttivat konfigurointiyksiköiden (CU:iden) kuntoon. Toteutamme resurssipalvelumallia (RSM), joka voi käyttää joko sisäistä CMDB:tä tai liittää ulkoista - pilottiprojektin aikana asiakas ei yhdistänyt omaa CMDB:tä.
Käyttöliittymä resurssi-palvelumallin kanssa työskentelemiseen. Pilotti RSM.
No, itse asiassa asiakkaalla on vihdoin yksi valvontaruutu, jossa näkyvät tapahtumat eri järjestelmistä. Tällä hetkellä "sateenvarjoon" on kytketty kaksi järjestelmää - Zabbix ja Prometheus sekä itse alustan sisäinen valvontajärjestelmä.
Analyticsin käyttöliittymä. Yksi valvontanäyttö.
Prosessiautomaatio käynnistettiin
Tapahtumien seuranta laukaisi esikonfiguroitujen toimintojen käynnistämisen - hälytysten lähettäminen, komentosarjojen suorittaminen, tapausten rekisteröinti/rikastaminen - jälkimmäistä ei kokeiltu tämän asiakkaan kanssa, koska pilottiprojektissa ei ollut integraatiota palvelupisteeseen.
Toimintoasetusten käyttöliittymä. Lähetä hälytykset Slackiin ja käynnistä palvelin uudelleen.
Laajennettu tuotteen toiminnallisuus
Kun keskusteltiin automaatiokomentosarjoista, asiakas pyysi bash-tukea ja käyttöliittymää, jossa nämä skriptit voidaan konfiguroida kätevästi. Uudessa versiossa on tehty hieman enemmän (kyky kirjoittaa täysimittaisia loogisia rakenteita Luassa cURL-, SSH- ja SNMP-tuella) ja toteutettu toiminnallisuus, jonka avulla voit hallita komentosarjan elinkaarta (luo, muokkaa, versionhallinta , poista ja arkistoi).
Käyttöliittymä automaattisten korjausskriptien kanssa työskentelemiseen. Palvelimen uudelleenkäynnistyskomentosarja SSH:n kautta.
Keskeiset havainnot
Pilotin aikana syntyi myös käyttäjätarinoita, jotka parantavat nykyistä toimivuutta ja lisäävät arvoa asiakkaalle, tässä muutamia:
- toteuttaa kyky välittää muuttujat suoraan hälytyksestä automaattiseen korjausskriptiin;
- Lisää käyttöoikeus alustalle Active Directoryn kautta.
Ja saimme lisää globaaleja haasteita - "rakentamaan" tuotetta muilla ominaisuuksilla:
- automaattinen resurssi-palvelumallin rakentaminen perustuen ML:ään sääntöjen ja agenttien sijaan (todennäköisesti suurin haaste nyt);
- tuki ylimääräisille komentosarja- ja logiikkakielille (ja tämä on JavaScript).
Mielestäni tärkein asiaTämä pilotti näyttää kaksi asiaa:
- Kumppanuudet asiakkaan kanssa ovat tehokkuuden avain, kun tehokas viestintä rakentuu rehellisyyden ja avoimuuden pohjalle ja asiakkaasta tulee osa tiimiä, joka saavuttaa merkittäviä tuloksia lyhyessä ajassa.
- Missään tapauksessa ei ole tarpeen "räätälöidä" ja rakentaa "sauvoja" - vain järjestelmäratkaisuja. On parempi viettää hieman enemmän aikaa, mutta tehdä järjestelmäratkaisu, jota muut asiakkaat käyttävät. Muuten, näin tapahtui, laajennusjärjestelmä ja Azure-riippuvuuden poistaminen toivat lisäarvoa muille asiakkaille (hei, liittovaltion laki 152).
Lähde: will.com