Hvorfor DevOps ikke integreres godt i russisk virksomhet og hvem som har skylden

Hva er DevOps og hvilke oppgaver en DevOps-ingeniør gjør

Begrepet DevOps (Development Operations, eller operasjoner innenfor

utvikling - "High-tech") ble først brukt i2009 IT-konsulent Patrick Debois. I hovedsak betyr det ikke bare en ledig stilling, men en hel metodikk som lar deg lage digitale produkter mer effektivt og raskt. Et beslektet sett med verktøy fra utvikling, produktadministrasjon, programvareutvikling og andre spesialiteter sikrer en kontinuerlig programvareopprettingsprosess.

Et rikt arsenal av praksis bringer DevOps nærmere andrepopulær innen IT-området ved hjelp av Agile-metoden. Det er en iterativ designtilnærming som lar deg tilpasse seg endrede krav. Følgelig prøver DevOps-spesialisten å gjøre produktet bedre, og forretningsprosessene mer forutsigbare og mer gjennomsiktige. Det forbedrer også forretningsverdiene, for eksempel å forkorte Time-to-Market. Dette er tiden fra starten av produktutviklingen til markedslanseringen. Kunnskap om faktorene som strekker tiden for å lage programvare og en systemtilnærming, gjør at DevOps-ingeniøren kan gjøre produksjonen kontinuerlig og rask. For å gjøre det tydeligere kan du tegne en analogi med et transportbånd for montering av biler. Alle deler er designet på forhånd slik at de passer perfekt sammen under montering. Ingeniører som designer en motor, tenker på hvordan den fungerer sammen med hjul, bremser og så videre. DevOps gjør det samme: tar ansvar for mer av produktet enn utvikleren gjør, og sørger for at alle lag samarbeider.

Pink Pony World: Race for Fashion Philosophy

Imidlertid trenger ikke alle selskaper DevOps.For eksempel, i team uten eksisterende IT-avdelinger som ikke er involvert i produksjonen av et digitalt produkt, gjelder DevOps-filosofien ikke i det hele tatt. Disse områdene inkluderer selskaper hvis fortjeneste ikke direkte avhenger av hvor fornøyde kunder er med IT-produktet de kommuniserer med. I tillegg er det ofte ikke egnet for små bedrifter. Metodikken krever endringer i mange etablerte forretningsprosesser og til og med bedriftskultur. Små selskaper tåler ganske enkelt ikke slike endringer fra prosjektøkonomisk synspunkt.

Den fasjonable sykdommen med digital transformasjon er oftegjelder lederne for slike selskaper. I jakten på endeløs optimalisering glemmer de andre faktorer som påvirker virksomheten. Som et resultat taper selskaper penger, effektivitet og i verste fall forretningsprosesser som har blitt bygget opp gjennom årene. IT-giganter, banker, store handels- og industriarrangementer er en annen sak. For dem kan DevOps være veldig gunstig. I følge årsrapporten til Alfa-Bank for 2017 tillot implementeringen av metodikken oss dermed å akselerere utviklingen og implementeringen 60 ganger.

Stakhanovite-mnogostanochnik i stedet for verksted for ansatte

Selvfølgelig er så omfattende funksjonalitet vanskeligper ansatt, så ideelt sett er et helt tverrfunksjonelt team involvert i DevOps. Det inkluderer fagpersoner i roller og prosess- og produktledere, infrastruktur kodeutvikler, ingeniør og mange andre roller. Imidlertid, i russisk praksis, kan en DevOps-spesialist ofte bli en fasjonabel måte å spare penger på produktopprettelse. Vanligvis oppstår denne situasjonen etter at toppsjefen i selskapet bestemmer at tiden er inne for digital transformasjon. Selskapet rekrutterer raskt nye spesialister eller utvider listen over ansvar for eksisterende utviklere og systemadministratorer. Som et resultat skaper rekrutteringstjenester ikke ledige stillinger for DevOps-ingeniører, men for ansatte med flere stasjoner.

En slik ansatt kan være forpliktet individueltkonfigurere servere, legge kabelsystemer, og deretter spore feil, konfigurere databaser og prosjektvert, og så videre. Dette eksemplet er ekstremt, men ekte. Som et resultat brenner ansatte raskt ut, og implementeringen av metodikken i arbeidet til selskapet mislykkes. Å behandle en DevOps-spesialist som en magiker som samtidig kan håndtere et stort antall oppgaver, kombinert med å overvåke driften av hele systemet, vil ikke gi fortjeneste til virksomheten.

Et annet vanlig problem er relatert tildele laget i to grupper som ikke kan komme overens med hverandre. Tenk deg at et IT-selskap har en DevOps-avdeling, som har lov til å endre de vanlige arbeidsprosedyrene. Imidlertid forblir disse reglene bindende for andre utviklere. Selvfølgelig er det i dette tilfellet ikke nødvendig å snakke om samarbeid og "sømløshet" i arbeidet. De to lagene begynner å kollidere og produktiviteten synker.

Et fat pulver i lasterommet: DevOps er ikke bare ferdigheter

En av oppgavene til DevOps-avdelingen er å etablerekommunikasjon mellom forskjellige IT-spesialister i selskapet. DevOps-ingeniører bør ikke bare introdusere teknologier og feilsøkingsprosesser, men også fordype utviklingsteamet i løpet av virksomheten - dele ansvar, bidra til å øke kompetansen. Likevel håndterer slike spesialister ofte rent tekniske oppgaver, vanligvis på grunn av den banale mangelen på tid, både for dem og de hvis kompetanse må økes.

Som et resultat, på grunn av det faktum at den introduserte fasjonableAlle bruker teknologier, og kunnskap og ferdigheter er konsentrert i en avdeling, det oppstår problemer, inkludert katastrofale. Nye løsninger opprettet av DevOps-ingeniører, uten godt koordinert arbeid fra forskjellige avdelinger, kan gi så mange problemer som de burde ha løst i utgangspunktet, noe som ikke betyr at DevOps-spesialister skal lage en bedriftskultur fra bunnen av, som tilsynelatende innenlandske ledere. Enheten i den digitale produksjonsrørledningen og oppmuntring til overføring av nye ferdigheter og kommunikasjon må komme fra selskapets ledere. Uten dette vil selv DevOps-teamet utvikle seg dårlig og ikke dele kunnskap med teamet.

Verken DevOps outsourcing ellerrådføre seg med en spesialist utenfra. I det første tilfellet styres det eksterne teamet ikke av kundeselskapets behov, men av det standard settet med teknologier som er sitert på markedet. For klienten er dette et lotteri: outsourcede ansatte bruker en vag forståelse av DevOps i markedet. Som et resultat blir forretningsprosesser mer og mer komplekse, men dette gir ingen fordeler for virksomheten. Ofte oppmuntrer bedrifter selv denne tilnærmingen - for eksempel når de ber dem om ikke å endre utviklingsprosessene. Det er klart at dette er i strid med selve konseptet med DevOps.

Lang, dyr, problematisk: harde DevOps på russisk

I stedet for å bruke DevOps-filosofien påtil alle forretningsprosesser foretrekker ofte innenlandske selskaper å jobbe med verktøy som ikke vil påvirke arbeidshastigheten. Et av resultatene er for eksempel "murveggen" - Operasjoner, det vil si teamet av systemadministratorer, forblir isolert, og utviklerne bare kaster applikasjoner på dem. Selvfølgelig forbedres verktøykassen som et resultat. Imidlertid skjer ikke grunnleggende endringer, gjennomsiktigheten øker ikke, og samarbeidet om IT-team forbedres ikke.

Nok en hake de snubler overledere ved implementering av DevOps - mangel på bedriftens kunnskapsbaser. I følge DORA-rapporten for 2019 var team som brukte interne selskapsinformasjonskilder 1,73 ganger mer effektive enn andre. Dette problemet kommer igjen ned til den lukkede kulturen til mange russiske selskaper, der teamet ikke deler kunnskap. På grunn av denne lukkede naturen begynner selskaper å samle teknisk gjeld. Verktøyene blir utdaterte, artefakter fjernes ikke, dokumentasjon oppdateres ikke.

Det objektive forretningsbehovet for produksjonsstabilitet, og dermed profitt, kombinert med en utdatert teknologibase og teknisk gjeld fører til mislykket bruk av DevOps.

Alt dette fører ofte til at nye løsninger som tilbys av DevOps-teamet, etter lang kval, rett og slett kastes, og prosessene blir "rullet tilbake".

Hvert selskap har sin egen vei for digital transformasjon.I de fleste tilfeller endrer det virkelig hvordan koden din blir utviklet og distribuert til det bedre. Dette betyr at DevOps fortsatt eksisterer i Russland: hver måned vises det mange ledige stillinger relatert til denne metoden. En annen ting er at det er forskjellige definisjoner av spesialiteten og praktiske oppgaver som ligger bak dem. Imidlertid bør selskaper slutte å jage spøkelsesrike IT-systemer og være kritiske til å ta i bruk en trendy, men ikke nødvendigvis lønnsom filosofi, og prioritere sine egne behov.

Se også:

Det kan være universer i sorte hull. Vi forteller deg om den nye oppdagelsen

På sykdomsdag 3 mister de fleste COVID-19 pasienter luktesansen og lider ofte av en rennende nese

Forskning: 15 millioner tonn mikroplast funnet på havbunnen