Az Unum Group építésze felvázolja a DevOps tanfolyamot a hibrid felhő jövőjére

Gardner: Beszéljünk egy kicsit arról, hogy mi a fontos cége számára. Ön egy nagy biztosító. Benne vagy a Fortune 500-ban. Ön az egyik legnagyobb munkavállalói juttatási szolgáltató az Egyesült Államokban, és nagy jelenléte van az Egyesült Királyságban is. Melyek azok a kényszerek, amelyek arra késztették Önt, hogy megpróbáljon javítani az alkalmazások kézbesítésén?

Durgan: Annak ellenére, hogy amint mondta, mi vagyunk az egyik legnagyobb munkavállalói juttatási szolgáltató az Egyesült Államokban, kezdtük felismerni, hogy a piac egyes szegmenseiben kisebb cégek kezdenek szétválni.

Durgan

Elengedhetetlenné vált a termékek gyorsabb piacra juttatása, mert a szállítás több éves erőfeszítés volt, ami elfogadhatatlan. Ha ennyi ideig tartana a koncepciótól a szállításig, teljesen új piaci dinamika játszana.

Elkezdtük nézni az alkalmazásarchitektúrákat, mint pl szolgáltatásorientált architektúra (SOA) agilitásra, folyamatautomatizálásra és szabályautomatizálásra – mindez nagyon általános megközelítés. Elég hamar rájöttünk, hogy ezeknek a megközelítéseknek a hatékony használatához bizonyos szintű kormányzásra van szükség.

Kormányzási kezdeményezés

WVolt egy SOA-irányítási kezdeményezés, amelyet én vezettem, és a HP technológiáját hoztuk segítségül. Ez volt a Business Service Management (BSM) eszközkészlet, a Systinet Repositoryés néhány HP partnertermék.

Amit nagyon gyorsan felfedeztünk, az az vállalati architektúra, ahonnan a cégnél származom, egy olyan működési eszköz bevezetését, mint a monitorozás, nem úgy méltatták, hogy "Köszönöm, hogy segítettél." Volt ez a szervezeti visszaszorítás. Korán világossá vált számomra, hogy silókban működünk. A kézbesítés mindent megtett, és mi átdobtuk a falon QA. A minőségbiztosítás elvégezné a dolgát, majd végül áthelyeznénk egy termelési környezetbe, és a működési szempontok veszik át a helyét.

Nagyon korán felötlött bennem, hogy meg kell próbálnunk megkérdőjelezni a szervezet körüli status quót. Ez késztetett arra, hogy erre a DevOps-ötletre összpontosítsam, és a HP-nek számos olyan terméke van, amelyek valóban lehetővé teszik, hogy ez a filozófia valósággá váljon.

Van néhány alapelvem, amelyeket használok, amikor a DevOps-ról beszélek, és megpróbálok címeket használni ezekhez az elvekhez, amelyek kissé zavaróak, így az emberek odafigyelnek.

Például azt fogom mondani, hogy „töröld ki a majmokat”, ami lényegében azt jelenti, hogy meg kell próbálnod a lehető legtöbbet automatizálni. Sok vállalatnál a fejlesztési folyamat tele van emberekből álló bizottságokkal, amelyek objektív kritériumok alapján döntenek. A gépek objektív kritériumok alapján nagyon jók. Tartsuk meg az embereket a szubjektív dolgoktól.

Erről beszélek, amikor azt mondjuk, tegyük ki a majmokat, húzzuk ki az embereket a középpontból. Nagyon érdekes, mert építészként felismerem az üzleti folyamatok automatizálását. De valahogy hiányoltam, hogy automatizálnunk kell az informatikai folyamatot, ami sok szempontból a DevOps lényege.

Egy másik alapelv a „gyors kudarc”. Ha gyorsan akarsz szoftvert szállítani, akkor gyorsan meg kell tudnod bukni. Példának okáért, amit a tavalyi konferencián bemutattam – amit tudtam, hogy a HP-emberek többsége szeretett – az volt Tenyér. Biztos vagyok benne, hogy bárcsak gyorsabban buktak volna el, mert ez elég fájdalmas lecke volt, és sok cég küzd ezzel.

Unum igen. Szeretnénk gyorsan kiadni egy terméket, de ha kudarcot vallana, akkor szeretnénk tudni, hogy nagyon gyorsan meg fog bukni, nem pedig több millió dolláros befektetést.

A másik az egész láthatóság. Azt mondom, hogy a monitorozás csapatsport. Nagyon sok cégnél 50 vagy 60 felügyeleti eszköz van. Minden csapat rendelkezik egy megfigyelő eszközzel. Minden egyes megfigyelőeszköz használatához titkos dekódoló gyűrűvel kell rendelkeznie.

Noha a sokszínűség általában nagyszerű dolog, nem az, ha megfigyelésről van szó. Nem kérheti, hogy az operátor olyan adatokat nézzen meg, amelyek különböznek attól, amit a fejlesztő néz. Ez azt jelenti, hogy teljesen reménytelen vagy, amikor a problémák megoldásáról van szó.

Együttműködő munka

MAz utolsó a "Kumbaya". Sok informatikai szervezet versenyszerűen működik. Valahogy az infrastruktúra elhiszi, hogy sikeresek lehetnek fejlesztés és minőségbiztosítás nélkül, és fordítva. Az üzlet csak az IT-t látja. Egy komplett csapat vagyunk, és közösen kell dolgoznunk, hogy elérjünk valamit.

Szóval tényleg így gondolok a DevOps-ra a cégnél.

Gardner: Petri, amikor olyan szavakat hallasz, mint "folyamatautomatizálás informatikai célokra", és az IT-csoportok adatainak közös nézetét, az biztos zene a fülednek?

Maanonen: Oh biztos. A csapat pedig nagyon pontosan megragadta annak lényegét, hogy a DevOps-t funkcióként támogatni kell, és természetesen meg kell osztani a silókban lévő különféle csapatok között.

Maanonen

Ha megnézi a HP-t, mi 15 éve támogatjuk ezeket a különböző csapatokat, legyen szó egy alkalmazás teljesítményének teszteléséről, vagy a végfelhasználói szemszögből történő monitorozásról és így tovább. Így ügyfeleinktől megfigyeltük – és az Unum ennek egy zseniális példája –, hogy fejlesztik és fejlesztik saját belső együttműködésüket a DevOps folyamatok támogatására. Nyilvánvalóan a technológia jó támogató tényező ebben.

Tim megemlítette az üzlet által támasztott igények folyamatos szállítását. Igyekeztünk feljebb lépni, nem csak a technológia fejlesztésével, hanem valójában nagyon gyorsan támogató támogatással is szoftver, mint szolgáltatás (SaaS) az ajánlatok típusai, Agilis menedzser és Teljesítmény bárhol például. Ezután az ügyfelek gyorsan átvehetik a támogató technológiát, és elindíthatják ezt az együttműködést és a DevOps ciklust, a folyamatos fejlesztési ciklust.

Gardner: Amikor azt mondtad, Kumbaya, ez nyilvánvalóan arról szól, hogy az emberek lássák a látomást, vásároljanak a vízióból, majd cselekedjenek a vízió szerint. Szóval mesélj még egy kicsit, Tim, kb a politika DevOps.

Durgan: Szerintem nagyon sok cégnek és az Unumnak is az a problémája, hogy sajnos mindannyiunknak egyéni elvárásai és teljesítménye van. Az év végén mindannyiunknak teljesítményértékelést tartunk, és vannak tennivalóink. Tehát, ahogy említette, mindenkit rávenni kell arra, hogy vegyen részt a holisztikus vízióban, és hogy ezek a csoportok mind regisztráljanak a DevOps vízióra.

Jól sikerült a beszélgetés eddig az Unumnál. Tudom, hogy beszéltünk a technológiai igazgatónkkal, és ő nagyon támogatja ezt. De mivel még mindig úton vagyunk, adatokat, mutatókat és némi bizonyítékot szeretnénk a filozófia alátámasztására. Úgy gondolom, hogy a politikai térben haladunk előre, de ez még mindig kihívás.

Tagja vagyok a HP BSM CAB-nak (Customer Advisory Board), és ebben a csoportban ezekről a különböző kis monitorozási termékekről beszélnek, amelyek megpróbálják letörni a HP piacát. A termékmenedzserek megkérdezik: „Miért van ez? És azt mondom, hogy a probléma egy része az, hogy a BSM bevezeti a vállalatfelügyeletet.

Az a feltételezés, hogy sok szervezet csatlakozik a vállalatfelügyeleti vízióhoz. Sokan nem, mert az infrastruktúra-csapat törődik a szerverrel, az alkalmazáscsapat az alkalmazással, a hálózati csapat pedig a hálózattal. Sok szempontból ez ugyanaz a kihívás, mint a DevOps.

Láthatósági kérések

But Rengeteg kérést hallok az infrastruktúra- és alkalmazáscsapatoktól, hogy lássák egymás munkáját, tereit, és ezt hirdeti a DevOps. A DevOps azt mondja: „Láthatóságot szeretnénk biztosítani Önnek, mérnök, hogy megérthesse, mire van szüksége ennek az alkalmazásnak, és Láthatóságot szeretnénk biztosítani Önnek, fejlesztő, hogy mi történik a szerverkörnyezetben, hogy jobban együttműködhessen ott."

Nagyon sok szempontból létezik egy jó alulról építkező mozgalom, több, mint felülről lefelé. Ha politikáról beszélünk, akkor szerintem sok esetben ennek az „Occupy IT” mozgalomnak kell lennie.

Gardner: Melyek azok a megtérülések, amelyek kézzelfoghatóak és azonosíthatók, ha a DevOps megfelelően történik, amikor ezeket az adatokat megosztják, és van közös nézet, és elindulnak az automatizálási folyamatok?

Maanonen: Amit ügyfeleinktől hallunk, és ez alól nyilvánvalóan az Unum sem kivétel, az az, hogy képesek mérni a befektetés megtérülése (ROI) az állásidők számából vagy a megnövekedett termelékenységből vagy bevételből, csak elkerülve a régi alkalmazási problémákat, amelyek az együttműködési megközelítés nélkül előfordulhattak volna.

Emellett ott van a csökkentése a idő a megoldásra a problémákat, amelyeket a termelésben látnak, és a korábbinál több támogató adattal a fejlesztési és tesztelési ciklusokon keresztül megoldást nyújtanak. Ez sokkal gyorsabban történik, mint a múltban.

Ahol napokba vagy hetekbe telhetett az alkalmazás néhány hibájának kijavítása, ez az együttműködési folyamat miatt most órákon belül megtörténik.

Gardner: A DevOps jobb helyzetbe hoz-e téged ahhoz képest, amit úgy tűnik, mindannyian látunk a csukán lefelé haladva, Mobil-Először a mentalitás, aztán még több felhő lehetőségek?

Durgan: Ez az, ha a felhőbe való mozgásra gondolunk, amit Unum most nagyon figyel. Felhő-első stratégiát értékelünk. Az én felelősségem ennek a stratégiának a megírása.

És elkezd gondolkodni: "El fogom venni ezt az alkalmazást, és egy olyan adatközponton futtatom, amely már nincs a tulajdonomban. Tehát még nagyobb szükség van a láthatóságra, az átláthatóságra és az együttműködésre."

Ez egy olyan filozófia, amely lehetővé teszi az összes új felmerülő igényt, legyen szó mobilról, felhőről, API-k, a vállalkozás éle, mindazok a típusú jelenségek. Az egyik másik fontos dolog, amit korábban nem érintettünk, és amiről azt állítanám, hogy akadályt jelent a szervezetek számára, az az, ha a DevOps-ra gondolsz, és arra, hogy a láthatóság, az adatok nagyszerűek, de ha nincs fogalmad az elvárásokról, akkor ez csak adat.

Mit szólsz szolgáltatási szintű menedzsment (SLM) és ITIL folyamatok, folyamatok, amelyek megelőzték az ITIL-t, csak ez az elképzelés arról, hogy mik az elvárások, a teljesítmény, a rendelkezésre állás, mi van az IT-infrastruktúra vagy -alkalmazások bármely aspektusával kapcsolatban? Ha nincs kiforrott folyamatod, akkor nagyon nehéz kézzelfogható előrelépést elérni egy DevOps térben, ALM tér, vagy ezek közül bármelyik. Ez szervezési akadály is.

Váltsd valóra

OAz Unumnál az egyik dolog, hogy SLA-kat próbálunk létrehozni a fejlesztőtől kezdve, és ez az a hely, ahol gyorsan kudarcot vallunk, hogy valósággá tegyük. Amikor eljöttem a konferenciára és bemutattam, sok ember meglepődött. Szóval szerintem radikális.

Ha nem tudok megfelelni ennek az SLA-nak a fejlesztőben, akkor semmiféle változtatás nélkül nem fogok varázslatosan megfelelni a termelésben. És ez egy nagyszerű fejlesztés. Eleinte az emberek azt mondják, ez rettenetesen nagy teher, de megpróbálom azt mondani: „Nézd, fejlesztő, lehetőséget adok neked, hogy kudarcot vallj, és oldja meg a problémát hétfőtől péntekig, szemben a gyártási folyamattal, kudarcot vall, és hétvégén itt van, és a óra."

Számomra ez csak egyike azoknak a nagyon egyszerű dolgoknak, amelyek a DevOps filozófiájának, a sikertelen filozófiának a középpontjában állnak, és a fejlesztési ciklus nagy része. A DevOps eszköztárának nagy része jelenleg néhányra összpontosít ALM az elülső oldalon, HP Agile Manager, és a telepítés.

Nos, ezek nagyszerűek, de alkalmazástervezőként érdekel a tervezés és a fejlesztés. Úgy gondolom, hogy a HP jó helyzetben van ahhoz, hogy nagyszerű dolgokat hajtson végre a BSM-mel, amely minden SLA-adattal rendelkezik, és integrálja azokat olyan dolgokkal, mint a Repository, amely nagyszerű életciklus-kezeléssel rendelkezik. Elkezdődik ezek a végrehajtási pontok, és azt mondod: "Ez a kód csak akkor mozog, ha megfelel az SLA-nak." Ezt a döntést az eszköz, az objektív kritériumok hozzák meg, a rendszer dönti el. Nem szükséges, hogy ember legyen benne. Ez egy nagyszerű lehetőség a HP számára, hogy valóban élvonalbeli és piacvezető dolgokat csináljon.

Maanonen: Azt látjuk, hogy a felhő és a mobil, ahogy említette, Dana, bekerül a játékba, és növeli a végfelhasználók számára biztosított alkalmazások és szolgáltatások sebességét. Azt látjuk, hogy ez az egyre nagyobb hangsúly, a végfelhasználói szemszögből nézve a szolgáltatás igénybevételének, Legyen szó mobilról vagy felhőszolgáltatásról, technológiánk révén egyesítőként tettük ezt meg tényező.

Ez nagyon fontos, ha fel akarja törni a silókat. Ha a csapatok ezt a végfelhasználói szempontot alkalmazzák, a fejlesztés, tesztelés minden egyes lépésében a végfelhasználói élmény javítására összpontosítanak, és a monitorozás, ez tulajdonképpen közös nyelvet ad a csapatoknak, és növeli a jobb együttműködés esélyeit a szervezet.

Gardner: A HP egyedülálló lehet abban, hogy nagyon erős jelenléte van az alkalmazások tesztelésében, fejlesztésében, telepítésében, az Agile támogatásában és a DevOps támogatásában. De ezt csak egy építész láthatja. Mennyire lényeges a HP jövője szempontjából, hogy olyan építészeket tegyünk boldoggá, mint Tim?

Maanonen: Tim rámutatott, hogy hagyományos informatikai környezetből érkeznek, és most nagyon gyorsan áttérnek a felhőre. Így láthatja a HP portfólió szélességét. Bármely technológiai területet nézi is, elég jól felszereltnek kell lennünk ahhoz, hogy támogassuk az olyan cégeket és ügyfeleket, mint például Unum és mások utazásuk különböző fázisaiban és az érettségi görbén, amikor felhőbe, mobilba stb tovább. Nagyon szeretnénk kihasználni és megosztani az évek során itt szerzett tapasztalatainkat különböző ügyfelekkel.

De a portfólió szélessége a HP egyik erőssége, és igyekszünk minden területen versenyképesek maradni. Ezért örülök, hogy ezt megfigyelte a konferencián.

Gardner: Tim, mit szeretnél másképp látni – nem feltétlenül csak a termék szempontjából, hanem a tekintetben segít átjutni a szakadékon egy szilárd fejlesztő szervezetből, valamint egy szilárd adatközpontból és termelésből szervezet? Mire van szüksége ahhoz, hogy javítani tudjon ezen a DevOps kihíváson?

Durgan: A legnagyobb, amit a HP tehet értünk, az az, hogy továbbra is befektetünk a portfólió integrálásaiba, mert igaza van, a kínálatuk nagyon széles.

De úgy gondolom, hogy egy ekkora vállalatnál a HP számára az a kihívás, hogy saját silójuk legyen. Beszélhet a Systinet csapatával és a BSM csapatával, és megkérdezheti: "Még mindig ugyanazzal a céggel beszélek?" Szóval szerintem ezt az integrációt A kulcsrakész, mint az általunk elérni kívánt integrációk, a SOA Repository-jukat, a Systinet terméküket használják a SOA irányítás szíveként. projekt.

Integrálunk vele Minőségi Központ hogy a hibák láthatóak legyenek a tárolóban, így automatizált döntést hozhatunk arról, hogy ez a kód elköltözik, mert ésszerű számú hibája van. Azt szeretnénk mondani, hogy nulla, de legyünk őszinték, néha el kell engedni egyet, ha nem. Nagyon csekély minden Unum ember számára, aki ezt olvassa.

Ezután integráljuk a BSM-et, mert szeretnénk ezeket az SLA-adatokat és az SLM-adatokat, és integráljuk néhány partnerterméküket.

Remek lehetőség van ott. Ha ez az integráció simább, könnyebb dolog, kulcsrakész típusú művelet lehet, akkor az a portfólió, akkora valami, amit ténylegesen felhasználhat a DevOps jelentős vonzására hely.