Se sap que la competència del CTO només es posa a prova la segona vegada que exerceix aquesta funció. Perquè una cosa és treballar uns quants anys en una empresa, evolucionar amb ella i, en el mateix context cultural, anar cobrant més responsabilitat. I una altra cosa és arribar directament al càrrec de director tècnic d'una empresa amb un equipatge heretat i un munt de problemes escombrats perfectament sota la catifa.

En aquest sentit, l'experiència de Leon Fire, que va compartir DevOpsConf, no precisament únic, però multiplicat per la seva experiència i el nombre de rols diferents que va aconseguir provar al llarg de 20 anys, és molt útil. A sota del tall hi ha una cronologia d'esdeveniments al llarg de 90 dies i un munt d'històries que fan riure quan li passen a algú altre, però que no són tan divertides d'enfrontar-les en persona.

León parla molt colorit en rus, així que si teniu 35-40 minuts, us recomano veure el vídeo. Versió de text per estalviar temps a continuació.

La primera versió de l'informe era una descripció ben estructurada del treball amb persones i processos, que contenia recomanacions útils. Però no va transmetre totes les sorpreses que es van trobar al llarg del camí. Per tant, vaig canviar el format i vaig presentar els problemes que em van aparèixer davant com un jack-in-the-box a la nova empresa, i els mètodes per resoldre'ls per ordre cronològic.

Un mes abans

Com moltes bones històries, aquesta va començar amb l'alcohol. Estàvem asseguts amb amics en un bar, i com era d'esperar entre els informàtics, tothom plorava pels seus problemes. Un d'ells acabava de canviar de feina i parlava dels seus problemes amb la tecnologia, amb la gent i amb l'equip. Com més escoltava, més em vaig adonar que només m'havia de contractar, perquè aquests són els tipus de problemes que he estat resolent durant els últims 15 anys. Li ho vaig dir i l'endemà ens vam trobar en un entorn laboral. L'empresa es deia Teaching Strategies.

Teaching Strategies és líder del mercat en currículum per a nens molt petits des del naixement fins als tres anys. L'empresa tradicional "en paper" ja té 40 anys d'antiguitat, i la versió digital SaaS de la plataforma en fa 10. Fa relativament poc que s'ha iniciat el procés d'adaptació de la tecnologia digital als estàndards de l'empresa. La versió "nova" es va llançar el 2017 i era gairebé com l'antiga, només que va funcionar pitjor.

El més interessant és que el trànsit d'aquesta empresa és molt previsible: d'un dia a un altre, d'un any a un altre, podeu predir amb molta claredat quanta gent vindrà i quan. Per exemple, entre les 13 i les 15 de la tarda tots els nens de les llars d'infants van a dormir i els mestres comencen a introduir informació. I això passa cada dia, excepte els caps de setmana, perquè gairebé ningú treballa els caps de setmana.

Mirant una mica endavant, notaré que vaig començar la meva feina durant el període de més trànsit anual, que és interessant per diferents motius.

La plataforma, que semblava tenir només 2 anys, tenia una pila peculiar: ColdFusion i SQL Server del 2008. ColdFusion, si no ho saps, i molt probablement no ho sàpigues, és un PHP empresarial que va sortir a mitjans dels anys 90, i des de llavors ni tan sols n'he sentit a parlar. També hi havia: Ruby, MySQL, PostgreSQL, Java, Go, Python. Però el monòlit principal funcionava amb ColdFusion i SQL Server.

Problemes

Com més parlava amb els empleats de l'empresa sobre el treball i quins problemes es trobaven, més em vaig adonar que els problemes no només eren de naturalesa tècnica. D'acord, la tecnologia és antiga, i no hi van treballar, però hi va haver problemes amb l'equip i amb els processos, i l'empresa va començar a entendre-ho.

Tradicionalment, els seus tècnics s'asseien a la cantonada i feien algun tipus de feina. Però cada cop més negocis van començar a passar per la versió digital. Per això, l'últim any abans de començar a treballar, en van aparèixer de nous a l'empresa: consell d'administració, CTO, CPO i director de QA. És a dir, l'empresa va començar a invertir en el sector tecnològic.

Els rastres d'un llegat pesat no només es trobaven als sistemes. L'empresa tenia processos heretats, gent heretada, cultura heretada. Tot això s'havia de canviar. Vaig pensar que definitivament no seria avorrit i vaig decidir provar-ho.

Dos dies abans

Dos dies abans de començar una nova feina, vaig arribar a l'oficina, vaig omplir l'última documentació, vaig conèixer l'equip i vaig descobrir que l'equip estava lluitant amb un problema en aquell moment. Va ser que el temps mitjà de càrrega de la pàgina va saltar a 4 segons, és a dir, 2 vegades.

A jutjar pel gràfic, alguna cosa va passar clarament i no està clar què. Va resultar que el problema era la latència de xarxa al centre de dades: una latència de 5 ms al centre de dades es va convertir en 2 s per als usuaris. No sabia per què passava això, però en tot cas es va saber que el problema era al centre de dades.

Primer dia

Van passar dos dies i el meu primer dia de feina vaig descobrir que el problema no havia desaparegut.

Durant dos dies, les pàgines dels usuaris es van carregar de mitjana en 4 segons. Els pregunto si han trobat quin és el problema.

- Sí, vam obrir un bitllet.
- I?
- Bé, encara no ens han contestat.

Llavors em vaig adonar que tot el que m'havien explicat abans era només una petita punta de l'iceberg contra el qual havia de lluitar.

Hi ha una bona cita que s'adapta molt bé a això:

"De vegades, per canviar la tecnologia, cal canviar l'organització".

Però com que vaig començar a treballar en l'època més concorreguda de l'any, vaig haver de mirar les dues opcions per resoldre el problema: tant ràpid com a llarg termini. I comenceu pel que és crític ara mateix.

Tercer dia

Així, la càrrega dura 4 segons, i de 13 a 15 els pics més grans.

El tercer dia durant aquest període de temps, la velocitat de descàrrega era així:

Des del meu punt de vista, no va funcionar res. Des del punt de vista de tots els altres, funcionava una mica més lent del que és habitual. Però simplement no passa així: és un problema greu.

Vaig intentar convèncer l'equip, al qual van respondre que simplement necessitaven més servidors. Aquesta, per descomptat, és una solució al problema, però no sempre és l'única i la més eficaç. Vaig preguntar per què no hi havia prou servidors, quin era el volum de trànsit. Vaig extrapolar les dades i vaig trobar que tenim aproximadament 150 peticions per segon, la qual cosa, en principi, es troba dins de límits raonables.

Però no hem d'oblidar que abans d'obtenir la resposta correcta, cal fer la pregunta correcta. La meva següent pregunta va ser: quants servidors frontend tenim? La resposta "em va desconcertar una mica": teníem 17 servidors frontals!

— Em fa vergonya preguntar, 150 dividit per 17 et dóna uns 8? Vols dir que cada servidor permet 8 peticions per segon, i si demà hi ha 160 peticions per segon, necessitarem 2 servidors més?

Per descomptat, no necessitàvem servidors addicionals. La solució es trobava en el propi codi i a la superfície:

var currentClass = classes.getCurrentClass();
return currentClass;

Hi havia una funció getCurrentClass(), perquè tot el que hi ha al lloc funciona en el context d'una classe, és així. I per a aquesta funció hi havia a cada pàgina Més de 200 peticions.

La solució d'aquesta manera va ser molt senzilla, ni tan sols vau haver de reescriure res: simplement no torneu a demanar la mateixa informació.

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

Estava molt content perquè vaig decidir que només el tercer dia havia trobat el problema principal. Com era ingenu, aquest era només un dels molts problemes.

Però resoldre aquest primer problema va fer caure el gràfic molt més avall.

Al mateix temps, estàvem fent altres optimitzacions. Hi havia moltes coses a la vista que es podrien arreglar. Per exemple, el mateix tercer dia vaig descobrir que després de tot hi havia una memòria cau al sistema (al principi vaig pensar que totes les peticions venien directament de la base de dades). Quan penso en una memòria cau, penso en Redis o Memcached estàndard. Però jo era l'únic que ho pensava, perquè aquest sistema utilitzava MongoDB i SQL Server per a l'emmagatzematge en memòria cau, el mateix des del qual s'acaben de llegir les dades.

Dia deu

La primera setmana vaig tractar problemes que calia resoldre ara mateix. En algun lloc de la segona setmana, vaig venir al stand-up per primera vegada per comunicar-me amb l'equip, per veure què estava passant i com anava tot el procés.

Es va tornar a descobrir alguna cosa interessant. L'equip estava format per: 18 desenvolupadors; 8 provadors; 3 gestors; 2 arquitectes. I tots participaven de rituals comuns, és a dir, més de 30 persones venien cada matí al stand up i explicaven el que feien. És evident que la reunió no va durar ni 5 ni 15 minuts. Ningú va escoltar ningú perquè tothom treballa en sistemes diferents. En aquesta forma, 2-3 entrades per hora per a una sessió de preparació ja era un bon resultat.

El primer que vam fer va ser dividir l'equip en diverses línies de productes. Per a diferents seccions i sistemes, vam assignar equips separats, que incloïen desenvolupadors, provadors, gestors de productes i analistes empresarials.

Com a resultat hem obtingut:

• Reduint els stand-ups i les concentracions.
• Coneixement de la matèria del producte.
• Un sentiment de propietat. Quan la gent solia jugar amb els sistemes tot el temps, sabien que probablement algú altre hauria de treballar amb els seus errors, però no ells mateixos.
• Col·laboració entre grups. No cal dir que el control de qualitat no es comunicava gaire amb els programadors abans, el producte feia les seves coses, etc. Ara tenen un punt de responsabilitat comú.

Ens vam centrar principalment en l'eficiència, la productivitat i la qualitat: aquests són els problemes que vam intentar resoldre amb la transformació de l'equip.

Dia onze

En el procés de canviar l'estructura de l'equip, vaig descobrir com comptar HistòriaPunts. 1 SP era igual a un dia i cada bitllet contenia SP tant per al desenvolupament com per al control de qualitat, és a dir, almenys 2 SP.

Com vaig descobrir això?

Hem trobat un error: en un dels informes, on s'introdueix la data d'inici i finalització del període pel qual es necessita l'informe, no es té en compte l'últim dia. És a dir, en algun lloc de la sol·licitud no hi havia <=, sinó simplement <. Em van dir que això són tres Story Points, és a dir 3 dies.

Després d'això:

• S'ha revisat el sistema de valoració de Story Points. Ara les correccions d'errors menors que es poden passar ràpidament pel sistema arriben a l'usuari més ràpidament.
• Vam començar a combinar entrades relacionades per al desenvolupament i les proves. Abans, cada bitllet, cada error era un ecosistema tancat, no lligat a cap altra cosa. Canviar tres botons en una pàgina podria haver estat tres bitllets diferents amb tres processos de control de qualitat diferents en lloc d'una prova automatitzada per pàgina.
• Vam començar a treballar amb els desenvolupadors en un enfocament per estimar els costos laborals. Tres dies per canviar un botó no és divertit.

Dia vintè

En algun lloc a mitjans del primer mes, la situació es va estabilitzar una mica, vaig descobrir què passava bàsicament i ja vaig començar a mirar el futur i pensar en solucions a llarg termini.

Objectius a llarg termini:

• Plataforma gestionada. Centenars de peticions a cada pàgina no són serioses.
• Tendències previsibles. Hi havia pics de trànsit periòdics que a primera vista no es correlacionaven amb altres mètriques: calia entendre per què passava això i aprendre a predir.
• Ampliació de la plataforma. El negoci està en constant creixement, cada cop hi ha més usuaris i el trànsit augmenta.

En el passat es deia sovint: "Reescriurem-ho tot en [idioma/marc], tot funcionarà millor!"

En la majoria dels casos això no funciona, és bo si la reescriptura funciona. Per tant, havíem de crear un full de ruta: una estratègia específica que il·lustri pas a pas com s'aconseguiran els objectius empresarials (què farem i per què), que:

• reflecteix la missió i els objectius del projecte;
• prioritza els objectius principals;
• conté un calendari per assolir-los.

Abans d'això, ningú havia parlat amb l'equip sobre el propòsit dels canvis que es fessin. Això requereix les mètriques d'èxit adequades. Per primera vegada en la història de l'empresa, vam establir KPIs per al grup tècnic, i aquests indicadors estaven lligats als d'organització.

És a dir, els KPI de l'organització són compatibles amb els equips i els KPI d'equip són compatibles amb els KPI individuals. En cas contrari, si els KPI tecnològics no coincideixen amb els de l'organització, tothom es tira de la manta.

Per exemple, un dels KPI de l'organització està augmentant la quota de mercat mitjançant nous productes.

Com pots donar suport a l'objectiu de tenir més productes nous?

• En primer lloc, volem dedicar més temps a desenvolupar nous productes en lloc de solucionar defectes. Aquesta és una solució lògica que és fàcil de mesurar.
• En segon lloc, volem donar suport a un augment del volum de transaccions, perquè com més gran sigui la quota de mercat, més usuaris i, en conseqüència, més trànsit.

Aleshores, els KPI individuals que es poden executar dins del grup estaran, per exemple, al lloc d'on provenen els principals defectes. Si us centreu específicament en aquesta secció, podeu assegurar-vos que hi ha molts menys defectes i, aleshores, augmentarà el temps per desenvolupar nous productes i de nou per donar suport als KPIs de l'organització.

Així, cada decisió, inclosa la reescriptura del codi, ha de donar suport als objectius específics que l'empresa ens ha marcat (creixement organitzatiu, noves característiques, contractació).

Durant aquest procés, va sortir a la llum una cosa interessant, que es va convertir en notícia no només per als tècnics, sinó en general per a l'empresa: totes les entrades han d'estar enfocades com a mínim a un KPI. És a dir, si un producte diu que vol crear una funció nova, s'hauria de fer la primera pregunta: "Quin KPI admet aquesta funció?" Si no, ho sento, sembla una característica innecessària.

Dia trenta

A finals de mes, vaig descobrir un altre matís: ningú del meu equip d'operacions no ha vist mai els contractes que fem amb els clients. Podeu preguntar per què necessiteu veure els contactes.

• En primer lloc, perquè els SLA s'especifiquen als contractes.
• En segon lloc, els SLA són tots diferents. Cada client venia amb els seus requisits, i el departament comercial va signar sense mirar.

Un altre matís interessant és que el contracte amb un dels clients més grans estableix que totes les versions de programari suportades per la plataforma han de ser n-1, és a dir, no l'última, sinó la penúltima.

Està clar a quina distància estàvem de n-1 si la plataforma es basava en ColdFusion i SQL Server 2008, que ja no era compatible en absolut al juliol.

Dia quaranta-cinc

A mitjans del segon mes vaig tenir prou temps per seure i fer-ho valorcorrentcartografia completament per a tot el procés. Aquests són els passos necessaris que s'han de fer, des de la creació d'un producte fins a l'entrega al consumidor, i s'han de descriure amb el màxim de detall possible.

Es divideix el procés en petits trossos i veus què està prenent massa temps, què es pot optimitzar, millorar, etc. Per exemple, quant de temps triga una sol·licitud de producte a passar per la preparació, quan arriba a un bitllet que pot prendre un desenvolupador, control de qualitat, etc. Així que mireu cada pas individualment en detall i penseu què es pot optimitzar.

Quan vaig fer això, em van cridar l'atenció dues coses:

• alt percentatge de bitllets retornats des del control de qualitat als desenvolupadors;
• Les revisions de la sol·licitud d'extracció van trigar massa.

El problema era que aquestes eren conclusions com: Sembla que triga molt de temps, però no sabem quant de temps.

"No pots millorar allò que no pots mesurar".

Com justificar la gravetat del problema? Perd dies o hores?

Per mesurar-ho, hem afegit un parell de passos al procés Jira: "preparat per al desenvolupament" i "preparat per al control de qualitat" per mesurar quant de temps espera cada bitllet i quantes vegades torna a un pas determinat.

També hem afegit "en revisió" per saber quantes entrades hi ha de mitjana per a revisió, i a partir d'això pots començar a ballar. Teníem mètriques del sistema, ara vam afegir noves mètriques i vam començar a mesurar:

• Eficiència del procés: rendiment i planificat/entregat.
• Qualitat del procés: nombre de defectes, defectes de QA.

Realment ajuda a entendre què va bé i què no.

Dia cinquanta

Tot això, és clar, és bo i interessant, però cap a finals del segon mes va passar una cosa que, en principi, era previsible, tot i que no m'esperava tal escala. La gent va començar a marxar perquè l'alta direcció havia canviat. Va entrar gent nova a la direcció i va començar a canviar-ho tot, i els vells van renunciar. I normalment en una empresa que té diversos anys, tothom és amics i tothom es coneix.

Això s'esperava, però l'envergadura dels acomiadaments era inesperada. Per exemple, en una setmana dos líders d'equip van presentar simultàniament les seves renúncies per voluntat pròpia. Per tant, no només havia d'oblidar-me d'altres problemes, sinó centrar-me creant un equip. Aquest és un problema llarg i difícil de resoldre, però s'ha hagut de resoldre perquè volia salvar la gent que quedava (o la majoria). Calia reaccionar d'alguna manera davant el fet que la gent marxava per mantenir la moral a l'equip.

En teoria, això és bo: entra una persona nova que té carta blanca completa, que pot avaluar les habilitats de l'equip i substituir el personal. De fet, no es pot introduir gent nova per tantes raons. L'equilibri sempre és necessari.

• Vell i nou. Hem de mantenir gent gran que pugui canviar i donar suport a la missió. Però al mateix temps, hem de portar sang nova, d'això en parlarem una mica més endavant.
• Experiència. Vaig parlar molt amb bons júniors que tenien ganes i volien treballar amb nosaltres. Però no els vaig poder assumir perquè no hi havia prou gent gran per donar suport als júniors i fer-los de mentors. Primer calia reclutar el cim i només després els joves.
• Pastanaga i pal.

No tinc una bona resposta a la pregunta de quin és l'equilibri correcte, com mantenir-lo, quanta gent cal mantenir i quant empènyer. Aquest és un procés purament individual.

Dia cinquanta u

Vaig començar a mirar bé l'equip per entendre qui tenia, i una vegada més vaig recordar:

"La majoria dels problemes són problemes de les persones".

He descobert que l'equip com a tal, tant Dev com Ops, té tres grans problemes:

• Satisfacció amb l'estat actual de les coses.
• Falta de responsabilitat - perquè ningú ha portat mai els resultats del treball dels intèrprets per influir en el negoci.
• Por al canvi.

El canvi sempre et treu fora de la teva zona de confort, i com més joves són, més no els agrada el canvi perquè no entenen per què i no entenen com. La resposta més habitual que he sentit és: "No ho hem fet mai". A més, va arribar al punt de l'absurd total: els més petits canvis no es podrien produir sense que algú s'indignis. I per molt que els canvis afectessin la seva feina, la gent deia: “No, per què? No funcionarà".

Però no pots millorar sense canviar res.

Vaig tenir una conversa absolutament absurda amb un empleat, li vaig explicar les meves idees d'optimització, a les quals em va dir:
- Oh, no vas veure el que teníem l'any passat!
- I què?
"Ara és molt millor del que era".
- Aleshores, no es pot millorar?
- Per a què?

Bona pregunta: per què? És com si ara estigués millor del que era, aleshores tot és prou bo. Això comporta una manca de responsabilitat, cosa absolutament normal en principi. Com deia, el grup tècnic estava una mica al marge. L'empresa creia que haurien d'existir, però ningú no ha posat mai els estàndards. El suport tècnic mai va veure l'SLA, així que va ser bastant "acceptable" per al grup (i això em va cridar més l'atenció):

• 12 segons de càrrega;
• 5-10 minuts d'inactivitat cada llançament;
• La resolució de problemes crítics triga dies i setmanes;
• manca de personal de servei 24x7 / de guàrdia.

Ningú no va intentar preguntar-nos per què no ho fem millor, i ningú no s'ha adonat mai que no hauria de ser així.

Com a avantatge, hi havia un problema més: manca d'experiència. Els sèniors van marxar, i l'equip jove restant va créixer sota l'anterior règim i va ser enverinat per aquest.

A més de tot això, la gent també tenia por de fracassar i semblar incompetent. Això s'expressa en el fet que, en primer lloc, ells en cap cas va demanar ajuda. Quantes vegades hem parlat en grup i individualment, i he dit: "Fes una pregunta si no saps com fer alguna cosa". Tinc confiança en mi mateix i sé que puc resoldre qualsevol problema, però trigarà temps. Per tant, si puc preguntar a algú que ho sàpiga resoldre en 10 minuts, ho preguntaré. Com menys experiència tinguis, més por tindràs de preguntar perquè creus que seràs considerat incompetent.

Aquesta por a fer preguntes es manifesta de maneres interessants. Per exemple, preguntes: "Com estàs amb aquesta tasca?" - "Queden un parell d'hores, ja estic acabant." L'endemà torneu a preguntar, obteniu la resposta que tot està bé, però hi va haver un problema, definitivament estarà llest al final del dia. Passa un altre dia i fins que no et trobes a la paret i t'obliga a parlar amb algú, això continua. Una persona vol resoldre ell mateix un problema; creu que si no el resol ell mateix, serà un gran fracàs.

Per això els desenvolupadors van inflar les estimacions. Era aquella mateixa anècdota, quan discutien una tasca determinada, em van donar una figura tal que em va sorprendre molt. A la qual cosa em van dir que a les estimacions del desenvolupador, el desenvolupador inclou el temps en què es retornarà el bitllet de QA, perquè hi trobaran errors, i el temps que trigarà el PR i el temps durant el qual les persones que haurien de revisar estarà ocupat, és a dir, tot, el que sigui possible.

En segon lloc, persones que tenen por de semblar incompetents sobreanalitzar. Quan dius què s'ha de fer exactament, comença: "No, i si ho pensem aquí?" En aquest sentit, la nostra empresa no és única, és un problema estàndard per als joves.

Com a resposta, vaig introduir les pràctiques següents:

• Regla 30 minuts. Si no podeu resoldre el problema en mitja hora, demaneu ajuda a algú. Això funciona amb diferents graus d'èxit, perquè la gent encara no pregunta, però almenys el procés ha començat.
• Elimina tot menys l'essència, a l'hora d'estimar el termini per a la realització d'una tasca, és a dir, considerar només el temps que trigarà a escriure el codi.
• Aprenentatge continu per als que sobreanalitzin. És només un treball constant amb la gent.

Dia seixanta

Mentre feia tot això, era hora d'esbrinar el pressupost. Per descomptat, vaig trobar moltes coses interessants on gastàvem els nostres diners. Per exemple, teníem un bastidor sencer en un centre de dades independent amb un servidor FTP, que era utilitzat per un client. Va resultar que "... ens vam mudar, però ell es va quedar així, no el vam canviar". Va ser fa 2 anys.

Va ser especialment interessant la factura dels serveis al núvol. Crec que el motiu principal de l'alta factura del núvol són els desenvolupadors que tenen accés il·limitat als servidors per primera vegada a la seva vida. No cal que preguntin: "Si us plau, doneu-me un servidor de prova", poden prendre-ho ells mateixos. A més, els desenvolupadors sempre volen construir un sistema tan genial que Facebook i Netflix seran gelosos.

Però els desenvolupadors no tenen experiència en la compra de servidors i l'habilitat per determinar la mida requerida dels servidors, perquè abans no ho necessitaven. I normalment no entenen gaire la diferència entre escalabilitat i rendiment.

Resultats de l'inventari:

• Sortim del mateix centre de dades.
• Hem rescindit el contracte amb 3 serveis de registre. Perquè en teníem 5: cada desenvolupador que va començar a jugar amb alguna cosa en va prendre un de nou.
• S'han tancat 7 sistemes AWS. De nou, ningú va aturar els projectes morts; tots van continuar treballant.
• Costos de programari reduïts per 6 vegades.

Dia setanta-cinc

Va passar el temps, i en dos mesos i mig em vaig haver de reunir amb la junta directiva. El nostre consell d'administració no és millor ni pitjor que els altres; com tots els consells d'administració, vol saber-ho tot. La gent inverteix diners i vol entendre fins a quin punt el que fem encaixa en els KPI establerts.

La junta directiva rep molta informació cada mes: el nombre d'usuaris, el seu creixement, quins serveis utilitzen i com, rendiment i productivitat i, finalment, la velocitat mitjana de càrrega de la pàgina.

L'únic problema és que crec que la mitjana és pura maldat. Però és molt difícil explicar-ho a la junta directiva. Estan acostumats a operar amb números agregats, i no, per exemple, amb la dispersió dels temps de càrrega per segon.

Hi havia alguns punts interessants en aquest sentit. Per exemple, he dit que hem de dividir el trànsit entre servidors web separats en funció del tipus de contingut.

És a dir, ColdFusion passa per Jetty i nginx i llança les pàgines. I les imatges, JS i CSS passen per un nginx independent amb les seves pròpies configuracions. Aquesta és una pràctica bastant estàndard de la qual estic parlant va escriure fa un parell d'anys. Com a resultat, les imatges es carreguen molt més ràpid i... la velocitat mitjana de càrrega ha augmentat en 200 ms.

Això va passar perquè el gràfic es construeix a partir de les dades que inclou Jetty. És a dir, el contingut ràpid no s'inclou en el càlcul: el valor mitjà ha augmentat. Això ens ho va quedar clar, vam riure, però com podem explicar a la junta directiva per què vam fer alguna cosa i les coses van empitjorar un 12%?

Dia vuitanta-cinc

Al final del tercer mes, em vaig adonar que hi havia una cosa amb la qual no havia comptat gens: el temps. Tot el que he parlat porta temps.

Aquest és el meu calendari setmanal real: només una setmana laboral, no gaire ocupada. No hi ha prou temps per a tot. Per tant, de nou, cal reclutar persones que us ajudin a fer front als problemes.

Conclusió

Això no és tot. En aquesta història, ni tan sols he arribat a com hem treballat amb el producte i hem intentat sintonitzar-nos amb l'onada general, o com hem integrat el suport tècnic, o com hem resolt altres problemes tècnics. Per exemple, vaig saber per casualitat que a les taules més grans de la base de dades no fem servir SEQUENCE. Tenim una funció autoescrita nextID, i no s'utilitza en una transacció.

Hi havia un milió de coses semblants més de les quals podríem parlar durant molt de temps. Però el més important que encara cal dir és la cultura.

És la cultura o la manca d'aquesta la que porta a tots els altres problemes. Estem intentant construir una cultura on la gent:

• no tenen por dels fracassos;
• aprendre dels errors;
• col·laborar amb altres equips;
• prendre la iniciativa;
• assumir la responsabilitat;
• donar la benvinguda al resultat com a objectiu;
• celebrant l'èxit.

Amb això arribarà tota la resta.

Lleó Foc a twitter, facebook i mitjà.

Hi ha dues estratègies pel que fa al llegat: evitar treballar-hi a qualsevol preu o superar amb valentia les dificultats associades. Nosaltres c DevOpsConf Prenem el segon camí, canviant processos i plantejaments. Uneix-te a nosaltres youtube, llista d'enviament и telegrama, i junts implementarem una cultura DevOps.

Font: www.habr.com