La pregunta "com implementar devops" fa anys que existeix, però no hi ha molts bons materials. De vegades ets víctime dels anuncis de consultors no tan intel·ligents que necessiten vendre el seu temps, sigui com sigui. De vegades, aquestes són paraules vagues i extremadament generals sobre com les naus de les megacorporacions llauren les extensions de l'univers. La pregunta sorgeix: què ens importa això? Benvolgut autor, pots formular clarament les teves idees en una llista?
Tot això es deriva del fet que no s'ha acumulat gaire pràctica i comprensió real del resultat de les transformacions de la cultura de l'empresa. Els canvis de cultura són coses a llarg termini, els resultats de les quals no apareixeran en una setmana o un mes. Necessitem algú prou gran per haver vist com les empreses s'han construït i han fracassat al llarg dels anys.
John Willis - un dels pares de DevOps. John té dècades d'experiència treballant amb un gran nombre d'empreses. Recentment, en John va començar a notar patrons específics que tenen lloc quan es treballa amb cadascun d'ells. Utilitzant aquests arquetips, John guia les empreses pel veritable camí de la transformació de DevOps. Llegiu més sobre aquests arquetips a la traducció del seu informe de la conferència DevOops 2018.
Sobre el ponent:
Més de 35 anys en gestió informàtica, va participar en la creació del predecessor d'OpenCloud a Canonical, va participar en 10 startups, dues de les quals es van vendre a Dell i Docker. Actualment és vicepresident de DevOps i Pràctiques Digitals a SJ Technologies.
El següent és la història des del punt de vista de John.
Em dic John Willis i el lloc més fàcil per trobar-me és a Twitter, . Tinc el mateix àlies a Gmail i GitHub. A podeu trobar gravacions de vídeo dels meus informes i presentacions per a ells.
Tinc moltes reunions amb CIOs de diverses grans empreses. Sovint es queixen que no entenen què és DevOps i tots els que els intenten explicar-los parlen d'una cosa diferent. Una altra queixa habitual és que DevOps no funciona, tot i que sembla que els directors ho fan tot tal com se'ls va explicar. Estem parlant de grans empreses que tenen més de cent anys. Després de parlar amb ells, vaig arribar a la conclusió que, per a molts problemes, no és l'alta tecnologia la més adequada, sinó solucions de tecnologia relativament baixa. Durant setmanes vaig parlar amb gent de diferents departaments. El que veieu a la primera imatge de la publicació és el meu últim projecte, així es veia la sala després de tres dies de feina.
Què és DevOps?
De fet, si preguntes a 10 persones diferents, et donaran 10 respostes diferents. Però aquí hi ha l'interessant: les deu respostes seran correctes. Aquí no hi ha cap resposta incorrecta. Vaig estar força endinsat en DevOps durant uns 10 anys, i vaig ser el primer nord-americà al primer DevOpsDay. No diré que sóc més intel·ligent que tots els implicats en DevOps, però gairebé no hi ha ningú que s'hi hagi esforçat tant. Crec que DevOps es produeix quan el capital humà i la tecnologia s'uneixen. Sovint ens oblidem de la dimensió humana, tot i que parlem molt de tot tipus de cultures.
Ara tenim moltes dades, cinc anys de recerca acadèmica, prova de teories a escala industrial. El que ens diuen aquests estudis és que si combineu alguns patrons de comportament en una cultura organitzativa, podeu aconseguir una velocitat de 2000 vegades. Aquesta acceleració s'acompanya d'una millora igual en l'estabilitat. Aquesta és una mesura quantitativa del benefici que pot aportar DevOps a qualsevol empresa. Fa un parell d'anys, estava parlant de DevOps amb el CEO d'una empresa de Fortune 5000. Quan estava preparant la presentació, estava molt nerviós perquè havia de resumir els meus anys d'experiència en 5 minuts.
Al final vaig donar el següent Definició de DevOps: És un conjunt de pràctiques i patrons que permeten transformar el capital humà en capital organitzatiu d'alt rendiment. Un exemple és la manera com ha operat Toyota durant els últims 50 o 60 anys.
(A partir d'ara, aquests diagrames no es proporcionen com a material de referència, sinó com a il·lustracions. El seu contingut serà diferent per a cada empresa nova. Tanmateix, la imatge es pot veure per separat i ampliar-la
Una de les pràctiques d'aquest tipus més reeixides és mapeig de la cadena de valor. S'han escrit diversos bons llibres sobre això, el més reeixit dels quals és de Karen Martin. Però durant l'últim any, he arribat a la conclusió que fins i tot aquest enfocament és massa tecnològic. Sens dubte, té molts avantatges i l'he fet servir molt. Però quan el director general us pregunta per què la seva empresa no pot canviar a nous rails, és massa aviat per parlar de mapes de flux de valor. Hi ha moltes preguntes molt més fonamentals que primer cal respondre.
Crec que l'error que cometen molts dels meus companys és que simplement donen a l'empresa una guia de cinc punts i després tornen sis mesos després a veure què passa. Fins i tot un bon esquema com el mapatge de flux de valor té, diguem-ne, punts cecs. Després de centenars d'entrevistes amb directors de diverses empreses, he desenvolupat un patró determinat que ens permet desglossar el problema en els seus components, i ara parlarem de cadascun d'aquests components per ordre. Abans d'aplicar qualsevol solució tecnològica, faig servir aquest patró i, com a resultat, totes les meves parets estan cobertes amb diagrames. Recentment vaig estar treballant amb un fons d'inversió i vaig acabar amb 100-150 esquemes d'aquest tipus.
La mala cultura menja bons enfocaments per esmorzar
La idea principal és aquesta: cap quantitat de Lean, Agile, SAFE i DevOps ajudarà si la cultura de l'organització és dolenta. És com bussejar a profunditats sense equip de busseig o funcionar sense una radiografia. En altres paraules, parafrasejant Drucker i Deming: una mala cultura organitzativa s'empassarà qualsevol bon sistema sense sufocar-s'hi.
Per resoldre aquest problema principal, heu de seguir els passos següents:
- Fes que tot el treball sigui visible: cal fer visible tota la feina. No en el sentit que necessàriament s'ha de mostrar en alguna pantalla, sinó en el sentit que ha de ser observable.
- Sistemes de gestió del treball consolidats: cal consolidar els sistemes de gestió. En el problema del coneixement “tribal” i del coneixement institucional, en 9 casos de cada 10 el coll d'ampolla són les persones. En el llibre el problema va ser amb una sola persona, Brent, que va fer que el projecte tingués tres anys de retard. I em trobo amb aquests "Brents" per tot arreu. Per resoldre aquests colls d'ampolla, faig servir els dos elements següents de la nostra llista.
- Metodologia de la teoria de les restriccions: teoria de les restriccions.
- Hacks de col·laboració: hacks de col·laboració.
- Toyota Kata (): No parlaré gaire del Toyota Kata. Si t'interessa, al meu github sobre gairebé tots aquests temes.
- Organització orientada al mercat: organització orientada al mercat.
- Auditors de torn a l'esquerra: auditoria en les primeres etapes del cicle.
Començo a treballar amb una organització de manera molt senzilla: vaig a l'empresa i parlo amb els empleats. Com podeu veure, no hi ha alta tecnologia. Tot el que necessites és alguna cosa per escriure. Reuneixo diversos equips en una habitació i analitzo el que em diuen des de la perspectiva dels meus 7 arquetips. I després els dono ells mateixos un retolador i els demano que anotin a la pissarra tot el que han dit en veu alta fins ara. Normalment en aquest tipus de reunions hi ha una persona que ho anota tot i, en el millor dels casos, pot anotar el 10% de la discussió. Amb el meu mètode, aquesta xifra es pot augmentar a un 40%.
(Aquesta il·lustració es pot veure per separat )
El meu enfocament es basa en el treball de William Schneider. ). L'enfocament es basa en la idea que qualsevol organització es pot dividir en quatre quadrats. Aquest esquema per a mi sol ser el resultat de treballar amb aquells centenars d'altres esquemes que sorgeixen en analitzar una organització. Suposem que tenim una organització amb un alt nivell de control, però amb poca competència. Aquesta és una opció extremadament indesitjable: quan tothom segueix la línia, però ningú sap què fer.
Una opció una mica millor és aquella amb un alt nivell de control i competència. Si aquesta empresa és rendible, potser no necessita DevOps. El més interessant és treballar amb una empresa que té un alt nivell de control, poca competència i cooperació, però alhora un alt nivell de cultura (cultiu). Això vol dir que l'empresa té molta gent a qui li agrada treballar i la rotació laboral és baixa.
(Aquesta il·lustració es pot veure per separat )
Em sembla que els mètodes amb pautes rígides acaben entrant en el camí d'aconseguir la veritat. En particular, en el mapeig de flux de valor, hi ha moltes regles sobre com s'ha d'estructurar la informació. En les primeres etapes del treball, de les quals parlo ara, ningú necessita aquestes regles. Si una persona amb un retolador a les mans descriu la situació real de l'empresa a la junta, aquesta és la millor manera d'entendre l'estat de les coses. Aquesta informació no arriba als directors. En aquest moment, és estúpid interrompre a la persona i dir que va dibuixar algun tipus de fletxa incorrectament. En aquesta etapa, és millor utilitzar regles senzilles, per exemple: l'abstracció de diversos nivells es pot crear simplement utilitzant marcadors de diversos colors.
Repeteixo, sense alta tecnologia. El marcador negre representa la realitat objectiva de com funciona tot. Amb un marcador vermell, la gent marca allò que no els agrada de l'estat actual de les coses. És important que ells escriguin això, no jo. Quan vaig al CIO després d'una reunió, no ofereixo una llista de 10 coses que s'han de solucionar. M'esforço per trobar connexions entre el que diuen les persones de l'empresa i els patrons provats existents. Finalment, un marcador blau suggereix possibles solucions al problema.
(Aquesta il·lustració es pot veure per separat )
Un exemple d'aquest enfocament es mostra ara més amunt. A principis d'aquest any vaig treballar amb un banc. La gent de seguretat allà estava convençuda que no haurien de venir a revisar el disseny i els requisits.
(Aquesta il·lustració es pot veure per separat )
I després vam parlar amb gent d'altres departaments i va resultar que fa uns 8 anys, els desenvolupadors de programari van acomiadar els treballadors de seguretat perquè estaven alentint la feina. I després es va convertir en una prohibició, que es donava per fet. Encara que en realitat no hi havia prohibició.
La nostra reunió va transcórrer d'una manera extremadament confusa: durant unes tres hores, cinc equips diferents no em van poder explicar què passava entre el codi i el muntatge. I això sembla que és el més senzill. La majoria dels consultors de DevOps assumeixen per endavant que tothom ja ho sap.
Aleshores, el responsable de la governança informàtica, que havia estat en silenci durant quatre hores, va cobrar vida de cop quan vam arribar al seu tema, i ens va ocupar molt de temps. Al final li vaig preguntar què en pensava de la reunió, i mai oblidaré la seva resposta. Va dir: "Acostumava a pensar que el nostre banc només tenia dues maneres de lliurar programari, però ara sé que n'hi ha cinc, i ni tan sols en sabia tres".
(Aquesta il·lustració es pot veure per separat )
L'última reunió en aquest banc va ser amb l'equip de programari d'inversió. Amb ella va resultar que escriure diagrames amb un retolador en un full de paper és millor que en una pissarra, i fins i tot millor que en una pissarra intel·ligent.
Les fotos que veieu són com era la sala de conferències de l'hotel el quart dia de la nostra reunió. I hem utilitzat aquests esquemes per cercar patrons, és a dir, arquetips.
Així doncs, faig preguntes als treballadors, ells anoten les respostes amb retoladors de tres colors (negre, vermell i blau). Analitzo les seves respostes per arquetips. Ara parlem de tots els arquetips en ordre.
1. Fes visible tot el treball: fes visible el treball
La majoria de les empreses amb les quals treballo tenen un percentatge molt alt de treball desconegut. Per exemple, és quan un empleat ve a un altre i simplement demana que faci alguna cosa. A les grans organitzacions, pot haver-hi un 60% de treball no planificat. I fins a un 40% del treball no està documentat de cap manera. Si fos Boeing, no tornaria a pujar al seu avió a la meva vida. Si només es documenta la meitat del treball, no se sap si aquest treball s'està fent correctament o no. Tots els altres mètodes resulten inútils: no té sentit intentar automatitzar res, perquè el 50% conegut pot ser la part més coherent i clara del treball, l'automatització de la qual no donarà grans resultats, i el pitjor. les coses estan a la meitat invisible. A falta de documentació, és impossible trobar tota mena de pirates i treballs amagats, no trobar colls d'ampolla, aquests mateixos “Brents” dels quals ja he parlat. Hi ha un llibre meravellós de Dominica DeGrandis . Ella revela cinc "fuites de temps" diferents (lladres del temps):
- Massa treball en procés (WIP)
- Dependències desconegudes
- Treball no planificat
- Prioritats en conflicte
- Treball descuidat
Aquesta és una anàlisi molt valuosa i el llibre és genial, però tots aquests consells no serveixen de res si només el 50% de les dades són visibles. Els mètodes proposats per Dominica es poden utilitzar si s'aconsegueix una precisió superior al 90%. Parlo de situacions en què un cap dóna a un subordinat una tasca de 15 minuts, però li porta tres dies; però el cap no sap realment que aquest subordinat depèn de quatre o cinc persones més.
El projecte Phoenix és una història meravellosa sobre un projecte que va arribar tres anys massa tard. Un dels personatges s'enfronta a l'acomiadament per això, i es troba amb un altre personatge que es presenta com una espècie de Sòcrates. Ell ajuda a esbrinar què va fallar exactament. Resulta que l'empresa té un administrador del sistema, el nom del qual és Brent, i tot el treball passa per ell d'alguna manera. En una de les reunions es pregunta a un dels subordinats: per què cada tasca de mitja hora dura una setmana? La resposta és una presentació molt simplificada de la teoria de les cues i la llei de Little, i en aquesta presentació resulta que amb un 90% d'ocupació, cada hora de treball dura 9 hores. Cada tasca s'ha d'enviar a set persones més, de manera que aquesta hora esdevingui 63 hores, 7 vegades 9. El que dic és que per utilitzar la llei de Little o qualsevol teoria complexa de les cues, almenys cal tenir dades.
Per tant, quan parlo de visibilitat, no vull dir que tot estigui a la pantalla, sinó que almenys tens dades. Quan ho fan, sovint resulta que hi ha una quantitat molt gran de treball no planificat que d'alguna manera s'envia a Brent quan no és necessari. I en Brent és un gran noi, mai dirà que no, però no li diu a ningú com fa la seva feina.
Quan l'obra és visible, les dades es poden classificar ordenadament (això és el que fa la Dominika a la foto), es pot aplicar l'abstracció de les filtracions de cinc temps i es pot aplicar l'automatització.
2. Consolidar els sistemes de gestió del treball: gestió de tasques
Els arquetips dels que parlo són una mena de piràmide. Si el primer es fa correctament, el segon ja és una mena de complement. Molts d'aquests no funcionen per a startups, cal tenir-los en compte per a empreses més grans com Fortune 5000. L'última empresa per a la qual vaig treballar tenia 10 sistemes de venda d'entrades. Un equip tenia Remedy, un altre va escriure algun tipus de sistema propi, un tercer va utilitzar Jira i alguns es van conformar amb el correu electrònic. El mateix problema sorgeix si l'empresa té 30 canonades diferents, però no tinc temps per parlar de tots aquests casos.
Parlo amb la gent exactament com es creen les entrades, què els passa després i com s'evita. El més interessant és que la gent de les nostres reunions parla amb força sinceritat. Vaig preguntar quantes persones posaven "impacte menor/sense" a les entrades que realment haurien de tenir "impacte important". Va resultar que gairebé tothom ho fa. No em dedico a la denúncia i intento de totes les maneres possibles no identificar persones. Quan em confessen alguna cosa sincerament, no dono la persona. Però quan gairebé tothom passa per alt el sistema, vol dir que tota la seguretat és essencialment aparador. Per tant, no es poden extreure conclusions de les dades d'aquest sistema.
Per resoldre el problema del bitllet, heu de triar un sistema principal. Si utilitzeu Jira, mantingueu-lo Jira. Si hi ha alguna alternativa, que sigui l'única. La conclusió és que les entrades s'han de veure com un pas més en el procés de desenvolupament. Cada acció ha de tenir un tiquet, que ha de fluir pel flux de treball de desenvolupament. Les entrades s'envien a l'equip, que les penja al guió i després es fa càrrec d'elles.
Això s'aplica a tots els departaments, incloses les d'infraestructura i operacions. En aquest cas, és possible formar almenys una idea plausible de l'estat de les coses. Un cop establert aquest procés, de sobte és fàcil identificar qui és el responsable de cada aplicació. Perquè ara rebem no el 50%, sinó el 98% dels nous serveis. Si aquest procés bàsic funciona, la precisió millora a tot el sistema.
Canalització de serveis
Això de nou només s'aplica a les grans corporacions. Si sou una empresa nova en un camp nou, arremangueu-vos les mànigues i treballeu amb el vostre Travis CI o CircleCI. Quan es tracta d'empreses de Fortune 5000, un cas concret que va passar al banc on treballava. Google va arribar a ells i se'ls va mostrar diagrames de sistemes IBM antics. Els nois de Google van preguntar amb confusió: on és el codi font d'això? Però no hi ha codi font, ni tan sols una GUI. Aquesta és la realitat amb la qual han de fer front les grans organitzacions: registres bancaris de 40 anys d'antiguitat en un sistema central antic. Un dels meus clients utilitza contenidors Kubernetes amb patrons d'interruptors, a més de Chaos Monkey, tot per a l'aplicació KeyBank. Però aquests contenidors finalment es connecten a una aplicació COBOL.
Els nois de Google estaven completament segurs que resoldrien tots els problemes del meu client, i després van començar a fer preguntes: què és IBM datapipe? Se'ls diu: això és un connector. Amb què es connecta? Al sistema Sperry. I això què és? Etcètera. A primera vista sembla: quin tipus de DevOps hi pot haver? Però de fet, és possible. Hi ha sistemes de lliurament que us permeten lliurar el flux de treball als equips de lliurament.
3. Teoria de les restriccions: Teoria de les restriccions
Passem al tercer arquetip: el coneixement institucional/"tribal". Per regla general, a qualsevol organització hi ha diverses persones que ho saben tot i ho gestionen tot. Aquests són els que porten més temps a l'organització i que coneixen totes les solucions.
Quan apareix això al diagrama, encercleo específicament aquestes persones amb un marcador: per exemple, resulta que un cert Lou és present a totes les reunions. I ho tinc clar: aquest és el Brent local. Quan el CIO tria entre jo amb una samarreta i sabatilles esportives i el tipus d'IBM amb un vestit, m'escullen perquè puc dir al director coses que l'altre no dirà i que potser no li agradaria escoltar. . Els dic que el coll d'ampolla de la seva companyia és algú que es diu Fred i algú que es diu Lou. Aquest coll d'ampolla s'ha de deslligar, el seu coneixement s'ha d'obtenir d'ells d'una manera o altra.
Per resoldre aquest tipus de problemes, puc, per exemple, suggerir l'ús de Slack. Un director intel·ligent preguntarà: per què? Normalment, en aquests casos, els consultors de DevOps responen: perquè tothom ho està fent. Si el director és realment intel·ligent, dirà: i què? I aquí acaba el diàleg. I la meva resposta a això és: perquè hi ha quatre colls d'ampolla a l'empresa, Fred, Lou, Susie i Jane. Per institucionalitzar els seus coneixements, primer cal introduir Slack. Tots els teus wikis són una ximpleria total perquè ningú sap de la seva existència. Si l'equip d'enginyeria està involucrat en el desenvolupament de front-end i back-end i tothom ha de saber que es pot posar en contacte amb l'equip de desenvolupament front-end o l'equip d'infraestructura amb preguntes. És llavors quan Lou o Fred probablement tindran temps per unir-se al wiki. I llavors a Slack algú podria preguntar per què, per exemple, el pas 5 no funciona. I llavors en Lou o en Fred corregiran les instruccions del wiki. Si establiu aquest procés, moltes coses es posaran al seu lloc per si soles.
Aquest és el meu punt principal: per recomanar qualsevol tecnologia d'alta qualitat, primer cal posar-les en ordre, i això es pot fer amb les solucions de baixa tecnologia que acabem de descriure. Si comenceu amb les altes tecnologies i no expliqueu per què es necessiten, aleshores, per regla general, això no acaba bé. Un dels nostres clients utilitza Azure ML, una solució molt econòmica i senzilla. Al voltant del 30% de les seves preguntes van ser respostes per la pròpia màquina d'autoaprenentatge. I això va ser escrit per operadors que no estaven involucrats en ciències de dades, estadístiques o matemàtiques. Això és significatiu. El cost d'aquesta solució és mínim.
4. Hacks de col·laboració: Hacks de col·laboració
El quart arquetip és la necessitat de combatre l'aïllament. La majoria de la gent ja ho sap: l'aïllament genera hostilitat. Si cada departament es troba al seu propi pis i les persones no s'entrecreuen de cap manera, excepte a l'ascensor, l'hostilitat entre ells sorgeix molt fàcilment. Però si, al contrari, la gent està a la mateixa habitació, ella marxa immediatament. Quan algú llança alguna acusació general, per exemple, tal o tal interfície no funciona mai, no hi ha res més fàcil de desconstruir aquesta acusació. Els programadors que van escriure la interfície només han de començar a fer preguntes específiques, i aviat quedarà clar que, per exemple, l'usuari simplement utilitzava l'eina de manera incorrecta.
Hi ha moltes maneres de superar l'aïllament. Una vegada em van demanar que consultés un banc a Austràlia, però em vaig negar a fer-ho perquè tinc dos fills i una dona. L'únic que podia fer per ajudar-los era recomanar-los narracions gràfices. Això és una cosa que està demostrat que funciona. Una altra manera interessant són les reunions de cafè magre. En una gran organització, aquesta és una excel·lent opció per difondre el coneixement. A més, podeu dur a terme devopsdays interns, hackatons, etc.
5. Coaching Kata
Com vaig advertir al principi, avui no parlaré d'això. Si esteu interessats, podeu fer-hi una ullada .
També hi ha una bona xerrada sobre aquest tema de Mike Rother:
6. Market Oriented: organització orientada al mercat
Aquí hi ha diferents problemes. Per exemple, persones "I", persones "T" i persones "E". Les persones "jo" són les que només fan una cosa. Normalment existeixen en organitzacions amb departaments aïllats. "T" és quan una persona és bona en una cosa però també és bona en altres coses. "E" o fins i tot "pinta" és quan una persona té moltes habilitats.
La llei de Conway funciona aquí (), que de la forma més simplificada es pot afirmar de la següent manera: si tres equips treballen al compilador, el resultat serà un compilador de tres parts. Per tant, si hi ha un alt nivell d'aïllament dins d'una organització, fins i tot Kubernetes, circuit breaker, extensibilitat de l'API i altres coses de luxe d'aquesta organització s'organitzaran de la mateixa manera que la pròpia organització. Estrictament segons Conway i per malgrat tots els joves frikis.
La solució a aquest problema s'ha descrit moltes vegades. Hi ha, per exemple, arquetips organitzatius descrits per Fernando Fernandez. Aquesta arquitectura problemàtica de la qual acabo de parlar, amb aïllament, és una arquitectura orientada a funcions. El segon tipus és el pitjor, l'arquitectura matricial, un embolic dels altres dos. El tercer és el que es veu a la majoria de startups, i les grans empreses també estan intentant igualar aquest tipus. És una organització orientada al mercat. Aquí optimitzem per aconseguir la resposta més ràpida a les peticions dels clients. Això de vegades s'anomena una organització plana.
Molta gent descriu aquesta estructura de diferents maneres, m'agrada la redacció crear/executar equips, a Amazon en diuen dos equips de pizza. En aquesta estructura, totes les persones del tipus "I" s'agrupen al voltant d'un mateix servei i, a poc a poc, s'apropen al tipus "T", i si hi ha la gestió adequada, fins i tot poden arribar a ser "E". El primer contraargument aquí és que aquesta estructura té elements innecessaris. Per què necessiteu un verificador a cada departament si podeu tenir un departament especial de verificadors? A la qual responc: els costos addicionals en aquest cas són el preu que tota l'organització es converteixi en el tipus "E" en el futur. En aquesta estructura, el provador aprèn progressivament sobre xarxes, arquitectura, disseny, etc. Com a resultat, cada participant de l'organització és plenament conscient de tot el que passa a l'organització. Si voleu saber com funciona aquest esquema a la indústria, llegiu .
7. Auditors de torn a l'esquerra: auditoria a principis del cicle. Compliment de les normes de seguretat a l'exposició
Això és quan les vostres accions no passen la prova de l'olfacte, per dir-ho d'alguna manera. La gent que treballa per a tu no és estúpida. Si, com en l'exemple anterior, van establir un impacte menor/no a tot arreu, això va durar tres anys, i ningú no es va adonar de res, llavors tothom sap perfectament que el sistema no funciona. O un altre exemple: un consell assessor de canvis, on els informes s'han de presentar cada dimecres, per exemple. Hi treballa un grup de persones (poc ben pagades, per cert) que, en teoria, haurien de saber com funciona el sistema en conjunt. I durant els últims cinc anys, probablement us heu adonat que els nostres sistemes són increïblement complexos. I cinc o sis persones han de prendre una decisió sobre un canvi que no han fet i del qual no saben res.
Per descomptat, aquest enfocament no funciona. He de desfer-me d'aquestes coses perquè aquesta gent no protegeix el sistema. La decisió l'ha de prendre el mateix equip, perquè l'equip n'ha de ser responsable. En cas contrari, es produeix una situació paradoxal quan un gestor que no ha escrit mai codi en la seva vida diu al programador quant de temps hauria de trigar a escriure codi. Una empresa amb la qual vaig treballar tenia 7 juntes diferents que revisaven cada canvi, inclòs un tauler d'arquitectura, un tauler de producte, etc. Fins i tot hi havia un període d'espera obligatori, tot i que un empleat em va dir que en deu anys de feina ningú havia rebutjat mai un canvi fet per aquesta persona durant aquest període obligatori.
Cal convidar els auditors a unir-se a nosaltres, i no desfer-se'n. Digues-los que escriviu contenidors binaris immutables que, si passen totes les proves, romandran immutables per sempre. Digues-los que tens un pipeline com a codi i explica què significa això. Mostra'ls el següent esquema: un binari immutable de només lectura en un contenidor que passa totes les proves de vulnerabilitat; i llavors no només ningú el toca, ni tan sols toquen el sistema que crea la canalització, ja que també es crea dinàmicament. Tinc clients, Capital One, que utilitzen Vault per crear alguna cosa com una cadena de blocs. L'auditor no necessita mostrar "receptes" de Chef; n'hi ha prou amb mostrar la cadena de blocs, de la qual queda clar què va passar amb el bitllet Jira en producció i qui n'és el responsable.
Segons , creat el 2018 per Sonatype, hi va haver 2017 milions de sol·licituds de descàrrega d'OSS el 87.
Les pèrdues ocasionades per vulnerabilitats són prohibitives. A més, les xifres que ara veieu més amunt no inclouen els costos d'oportunitat. Què és DevSecOps en poques paraules? Permeteu-me dir de seguida que no m'interessa parlar de l'èxit que té aquest nom. La qüestió és que com que DevOps ha tingut tant d'èxit, hauríem d'intentar afegir seguretat a aquesta canalització.
Un exemple d'aquesta seqüència:
Aquesta no és una recomanació per a productes concrets, tot i que m'agraden tots. Els vaig citar com a exemple per demostrar que DevOps, que inicialment es basava en el paradigma organitzatiu de la indústria, permet automatitzar cada etapa del treball d'un producte.
I no hi ha cap raó per la qual no podríem adoptar el mateix enfocament de la seguretat.
Total
Com a conclusió, donaré alguns consells per a DevSecOps. Heu d'incloure auditors en el procés de creació dels vostres sistemes i dedicar temps a educar-los. Cal col·laborar amb els auditors. A continuació, heu de fer una lluita absolutament despietada contra els falsos positius. Fins i tot amb l'eina d'escaneig de vulnerabilitats més cara, podeu acabar creant hàbits extremadament dolents entre els vostres desenvolupadors si no sabeu quina és la vostra relació senyal-soroll. Els desenvolupadors es veuran aclaparats amb esdeveniments i simplement els suprimiran. Si heu sentit parlar de la història d'Equifax, això és pràcticament el que va passar allà, on es va ignorar el nivell d'alerta més alt. A més, les vulnerabilitats s'han d'explicar de manera que quedi clar com afecten el negoci. Per exemple, podríeu dir que aquesta és la mateixa vulnerabilitat que a la història d'Equifax. Les vulnerabilitats de seguretat s'han de tractar de la mateixa manera que altres problemes de programari, és a dir, s'han d'incloure en el procés global de DevOps. Heu de treballar amb ells mitjançant Jira, Kanban, etc. Els desenvolupadors no haurien de pensar que algú més ho farà; al contrari, tothom hauria de fer-ho. Finalment, cal gastar energia en formar persones.
links útils
Aquí teniu algunes conferències de la conferència DevOops que us poden resultar útils:
- Sergey Berdnikov, Artyom Kalichkin - Cas d'èxit o "Dev+DevOps+Ops" (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps a escala: una tragèdia grega en tres actes (, )
- Alexander Titov, Kirill Tolkachev -
- Timothy Lister -
Investigar DevOops 2020 Moscou — També hi ha moltes coses interessants.
Font: www.habr.com