Hola, Habr! Porto deu anys donant suport als sistemes informàtics Highload. No escriuré en aquest article sobre els problemes de configurar nginx perquè funcioni en mode 1000+ RPS o altres coses tècniques. Compartiré les meves observacions sobre els problemes en els processos que sorgeixen en el suport i funcionament d'aquests sistemes.
Seguiment
L'assistència tècnica no espera fins que arribi una sol·licitud amb el contingut "Què Per què... el lloc no torna a funcionar?" Al cap d'un minut després del bloqueig del lloc, el suport ja hauria de veure el problema i començar a resoldre'l. Però el lloc és la punta de l'iceberg. La seva disponibilitat és una de les primeres a controlar.
Què fer amb la situació en què els productes restants d'una botiga en línia ja no arriben del sistema ERP? O ha deixat de respondre el sistema CRM que calcula els descomptes per als clients? Sembla que el lloc funciona. Zabbix condicional rep la seva resposta 200. El torn de servei no ha rebut cap notificació del seguiment i està veient feliçment el primer episodi de la nova temporada de Game of Thrones.
La supervisió sovint es limita a mesurar només l'estat de la memòria, la memòria RAM i la càrrega del processador del servidor. Però per a les empreses és molt més important tenir disponibilitat del producte al lloc web. La fallada condicional d'una màquina virtual del clúster farà que el trànsit deixi d'anar-hi i que la càrrega en altres servidors augmenti. L'empresa no perdrà diners.
Per tant, a més de supervisar els paràmetres tècnics dels sistemes operatius als servidors, cal configurar mètriques empresarials. Mètriques que afecten directament els diners. Diverses interaccions amb sistemes externs (CRM, ERP i altres). El nombre de comandes durant un període de temps determinat. Autoritzacions de client correctes o no i altres mètriques.
Interacció amb sistemes externs
Qualsevol lloc web o aplicació mòbil amb una facturació anual de més de mil milions de rubles interactua amb sistemes externs. Partint del CRM i ERP esmentats i acabant amb la transferència de dades de vendes a un sistema extern de Big Data per analitzar les compres i oferir al client un producte que definitivament comprarà (de fet, no). Cada sistema té el seu propi suport. I sovint la comunicació amb aquests sistemes provoca dolor. Sobretot quan el problema és global i cal analitzar-lo en diferents sistemes.
Alguns sistemes proporcionen un número de telèfon o telegrama per als seus administradors. En algun lloc cal escriure cartes als gestors o anar als rastrejadors d'errors d'aquests sistemes externs. Fins i tot en el context d'una gran empresa, els diferents sistemes sovint operen en diferents sistemes de comptabilitat d'aplicacions. De vegades es fa impossible fer un seguiment de l'estat d'una aplicació. Rebreu una sol·licitud en una Jira condicional. Després en el comentari d'aquesta primera Jira poses un enllaç al tema en una altra Jira. A la segona Jira de l'aplicació, algú ja està escrivint un comentari que heu de trucar a l'administrador condicional Andrey per resoldre el problema. I així successivament.
La millor solució a aquest problema seria crear un únic espai de comunicació, per exemple a Slack. Convidar tots els participants en el procés d'explotació de sistemes externs a unir-se. I també un únic rastrejador per no duplicar aplicacions. Les aplicacions s'han de fer un seguiment en un sol lloc, des de les notificacions de seguiment fins a la sortida de solucions d'errors en el futur. Diràs que això no és realista i històricament ha passat que treballem en un rastrejador i ells funcionen en un altre. Van aparèixer diferents sistemes, tenien els seus propis equips informàtics autònoms. Estic d'acord i, per tant, el problema s'ha de resoldre des de dalt a nivell de CIO o de propietari del producte.
Tots els sistemes amb els quals interactueu haurien de proporcionar suport com a servei amb un SLA clar per resoldre els problemes per prioritat. I no quan l'administrador condicional Andrey té un minut per a tu.
Home de coll d'ampolla
Tothom en un projecte (o producte) té una persona que marxa de vacances provoca convulsions entre els seus superiors? Pot ser un enginyer, analista o desenvolupador de devops. Després de tot, només un enginyer de devops sap quins servidors tenen quins contenidors instal·lats, com reiniciar el contenidor en cas d'un problema i, en general, qualsevol problema complex no es pot resoldre sense ell. L'analista és l'únic que sap com funciona el vostre complex mecanisme. Quins fluxos de dades van a on. Sota quins paràmetres de sol·licituds a quins serveis, quins rebrem respostes.
Qui entendrà ràpidament per què hi ha errors als registres i solucionarà ràpidament un error crític al producte? Per descomptat, el mateix desenvolupador. N'hi ha d'altres, però per alguna raó només ell entén com funcionen els diferents mòduls del sistema.
L'arrel d'aquest problema és la manca de documentació. Després de tot, si es descriguessin tots els serveis del vostre sistema, seria possible fer front al problema sense un analista. Si els devops van treure un parell de dies de la seva apretada agenda i descriuen tots els servidors, serveis i instruccions per resoldre problemes típics, aleshores el problema en la seva absència es podria resoldre sense ell. No cal que acabis ràpidament la teva cervesa a la platja mentre estàs de vacances i busques wi-fi per resoldre el problema.
Competència i responsabilitat del personal de suport
En els grans projectes, les empreses no escatimen els sous dels desenvolupadors. Busquen persones grans o mitjanes cars de projectes similars. Amb el suport la situació és una mica diferent. Estan intentant reduir aquests costos de totes les maneres possibles. Les empreses contracten treballadors econòmics d'Enikey d'ahir i entren a la batalla amb valentia. Aquesta estratègia és possible si estem parlant d'un lloc web de targetes de visita d'una planta de Zelenograd.
Si estem parlant d'una gran botiga en línia, llavors cada hora d'inactivitat costa més que el sou mensual d'un administrador d'Enikey. Prenem com a punt de partida 1 milions de rubles de facturació anual. Aquesta és la facturació mínima de qualsevol botiga en línia de la qualificació . Dividiu aquesta quantitat pel nombre d'hores a l'any i obteniu més de 100 rubles de pèrdues netes. I si no comptes les hores nocturnes, pots duplicar la quantitat amb seguretat.
Però els diners no són el principal, oi? (no, és clar, el més important) També hi ha pèrdues de reputació. La caiguda d'una coneguda botiga en línia pot provocar tant una onada de ressenyes a les xarxes socials com de publicacions en mitjans temàtics. I les converses d'amics a la cuina a l'estil de "No compreu res allà, la seva pàgina web sempre està baixa" no es poden mesurar en absolut.
Ara a la responsabilitat. A la meva pràctica, hi va haver un cas en què l'administrador de guàrdia no va respondre a temps a una notificació del sistema de seguiment sobre la indisponibilitat del lloc. En un agradable divendres al vespre d'estiu, el lloc web d'una coneguda botiga en línia de Moscou es trobava en silenci. Dissabte al matí, el gerent de producte d'aquest lloc no va entendre per què el lloc no s'obria, i hi va haver silenci en els xats d'assistència i notificacions urgents a Slack. Un error com aquest ens va costar una suma de sis xifres, i aquest oficial de servei la seva feina.
La responsabilitat és una habilitat difícil de desenvolupar. O ho té una persona o no. Per això, durant les entrevistes, intento identificar la seva presència amb diverses preguntes que indirectament mostren si una persona està acostumada a assumir responsabilitats. Si una persona respon que va triar una universitat perquè ho van dir els seus pares o canvia de feina perquè la seva dona va dir que no guanya prou, llavors és millor no involucrar-se amb aquestes persones.
Interacció amb l'equip de desenvolupament
Quan els usuaris troben problemes senzills amb un producte durant el funcionament, l'assistència els soluciona per si sol. Intenta reproduir el problema, analitza els registres, etc. Però, què fer quan apareix un error al producte? En aquest cas, el suport assigna la tasca als desenvolupadors i aquí és on comença la diversió.
Els desenvolupadors estan constantment sobrecarregats. Estan creant noves característiques. Arreglar errors amb les vendes no és l'activitat més interessant. S'acosten els terminis per completar el següent sprint. I aleshores vénen persones desagradables del suport i diuen: "Deixeu-ho de tot immediatament, tenim problemes". La prioritat d'aquestes tasques és mínima. Sobretot quan el problema no és el més crític i la funcionalitat principal del lloc funciona, i quan el gestor de llançaments no corre amb els ulls saltants i escriu: "Afegiu amb urgència aquesta tasca a la següent versió o correcció ràpida".
Els problemes amb prioritat normal o baixa es mouen de llançament a llançament. A la pregunta "Quan es completarà la tasca?" rebreu respostes a l'estil de: "Ho sento, hi ha moltes tasques ara mateix, pregunteu als líders del vostre equip o al gestor de llançaments".
Els problemes de productivitat tenen més prioritat que la creació de noves funcions. Les males crítiques no trigaran a arribar si els usuaris ensopeguen constantment amb errors. Una reputació danyada és difícil de restaurar.
DevOps resol els problemes d'interacció entre desenvolupament i suport. Aquesta abreviatura s'utilitza sovint en forma d'una persona específica que ajuda a crear entorns de prova per al desenvolupament, crea canalitzacions CICD i introdueix ràpidament el codi provat a la producció. DevOps és un enfocament del desenvolupament de programari quan tots els participants en el procés interactuen estretament entre ells i ajuden a crear i actualitzar ràpidament productes i serveis de programari. Em refereixo a analistes, desenvolupadors, provadors i suport.
En aquest enfocament, el suport i el desenvolupament no són departaments diferents amb les seves pròpies metes i objectius. El desenvolupament està implicat en l'operació i viceversa. La famosa frase dels equips distribuïts: "El problema no està del meu costat" ja no apareix tan sovint als xats i els usuaris finals es tornen una mica més feliços.
Font: www.habr.com