Ola, Habr! Levo dez anos apoiando sistemas de TI Highload. Non escribirei neste artigo sobre os problemas de configuración de nginx para que funcione en modo 1000+ RPS ou outras cousas técnicas. Vou compartir as miñas observacións sobre os problemas nos procesos que xorden no soporte e funcionamento deste tipo de sistemas.
Seguimento
O soporte técnico non agarda ata que chegue unha solicitude co contido "Que por que... o sitio non funciona de novo?" Dentro dun minuto despois de que o sitio falla, o soporte xa debería ver o problema e comezar a solucionalo. Pero o sitio é a punta do iceberg. A súa dispoñibilidade é unha das primeiras en vixiar.
Que facer coa situación na que os produtos restantes dunha tenda en liña xa non chegan do sistema ERP? Ou o sistema CRM que calcula os descontos para os clientes deixou de responder? O sitio parece estar funcionando. Zabbix condicional recibe a súa resposta 200. O turno de servizo non recibiu ningunha notificación da vixilancia e está encantado de ver o primeiro episodio da nova tempada de Game of Thrones.
A supervisión adoita limitarse a medir só o estado da memoria, a RAM e a carga do procesador do servidor. Pero para as empresas é moito máis importante obter a dispoñibilidade do produto no sitio web. O fallo condicional dunha máquina virtual do clúster provocará que o tráfico deixará de ir a ela e aumentará a carga noutros servidores. A empresa non perderá cartos.
Polo tanto, ademais de supervisar os parámetros técnicos dos sistemas operativos nos servidores, cómpre configurar as métricas empresariais. Métricas que afectan directamente ao diñeiro. Varias interaccións con sistemas externos (CRM, ERP e outros). O número de pedidos durante un período de tempo determinado. Autorizacións de clientes exitosas ou non e outras métricas.
Interacción con sistemas externos
Calquera sitio web ou aplicación móbil cunha facturación anual de máis de mil millóns de rublos interactúa con sistemas externos. Partindo dos mencionados CRM e ERP e rematando coa transferencia de datos de vendas a un sistema externo de Big Data para analizar as compras e ofrecerlle ao cliente un produto que definitivamente comprará (de feito, non). Cada un destes sistemas ten o seu propio soporte. E moitas veces a comunicación con estes sistemas causa dor. Sobre todo cando o problema é global e hai que analizalo en diferentes sistemas.
Algúns sistemas proporcionan un número de teléfono ou telegrama para os seus administradores. Nalgún lugar necesitas escribir cartas aos xestores ou ir aos rastreadores de erros destes sistemas externos. Mesmo no contexto dunha gran empresa, os diferentes sistemas adoitan operar en diferentes sistemas de contabilidade de aplicacións. Ás veces faise imposible rastrexar o estado dunha aplicación. Recibes unha solicitude nunha Jira condicional. Despois no comentario desta primeira Jira poñes unha ligazón ao tema noutra Jira. Na segunda Jira da aplicación, alguén xa está escribindo un comentario que cómpre chamar ao administrador condicional Andrey para resolver o problema. E así por diante.
A mellor solución a este problema sería crear un único espazo de comunicación, por exemplo en Slack. Convidando a todos os participantes no proceso de operación de sistemas externos a unirse. E tamén un único rastreador para non duplicar aplicacións. As aplicacións deben seguirse nun só lugar, desde as notificacións de seguimento ata a saída de solucións de erros no futuro. Dirás que isto non é realista e históricamente ocorreu que traballamos nun rastreador e eles traballan noutro. Apareceron diferentes sistemas, tiñan os seus propios equipos informáticos autónomos. Estou de acordo e, polo tanto, hai que resolver o problema desde arriba a nivel de CIO ou de produtor.
Todos os sistemas cos que interactúas deben proporcionar soporte como servizo cun SLA claro para resolver os problemas por prioridade. E non cando o administrador condicional Andrey ten un minuto para ti.
Home de pescozo de botella
Todo o mundo nun proxecto (ou produto) ten unha persoa cuxa marcha de vacacións provoca convulsións entre os seus superiores? Pode ser un enxeñeiro, analista ou programador devops. Despois de todo, só un enxeñeiro de devops sabe que servidores teñen que contedores instalados, como reiniciar o contedor en caso de problema e, en xeral, calquera problema complexo non se pode resolver sen el. O analista é o único que sabe como funciona o teu complexo mecanismo. Que fluxos de datos van onde. Baixo que parámetros de solicitudes a que servizos, cales recibiremos respostas.
Quen entenderá rapidamente por que hai erros nos rexistros e solucionará rapidamente un erro crítico no produto? Por suposto, o mesmo desenvolvedor. Hai outros, pero por algún motivo só el entende como funcionan os distintos módulos do sistema.
A raíz deste problema é a falta de documentación. Despois de todo, se se describían todos os servizos do seu sistema, sería posible xestionar o problema sen un analista. Se os devops sacaron un par de días da súa apretada axenda e describían todos os servidores, servizos e instrucións para resolver problemas típicos, entón o problema na súa ausencia podería resolverse sen el. Non necesitas rematar rapidamente a túa cervexa na praia mentres estás de vacacións e buscar wifi para resolver o problema.
Competencia e responsabilidade do persoal de apoio
Nos grandes proxectos, as empresas non escatiman nos salarios dos desenvolvedores. Buscan medios caros ou maiores de proxectos similares. Co apoio a situación é un pouco diferente. Están tentando reducir estes custos de todos os xeitos posibles. As empresas contratan traballadores económicos de Enikey de onte e van á batalla con audacia. Esta estratexia é posible se estamos a falar dun sitio web de tarxetas de visita dunha planta en Zelenograd.
Se estamos a falar dunha gran tenda en liña, cada hora de inactividade custa máis que o salario mensual dun administrador de Enikey. Tomemos 1 millóns de rublos de facturación anual como punto de partida. Esta é a facturación mínima de calquera tenda en liña da clasificación . Divide esta cantidade polo número de horas ao ano e obtén máis de 100 rublos de perdas netas. E se non contas as horas nocturnas, podes duplicar a cantidade con seguridade.
Pero o diñeiro non é o principal, non? (non, claro que o principal) Tamén hai perdas de reputación. A caída dunha coñecida tenda en liña pode provocar tanto unha onda de críticas nas redes sociais como publicacións en medios temáticos. E as conversas dos amigos na cociña ao estilo de "Non compre nada alí, o seu sitio web sempre está caído" non se poden medir en absoluto.
Agora á responsabilidade. Na miña práctica, houbo un caso no que o administrador de garda non respondeu a tempo a unha notificación do sistema de seguimento sobre a non dispoñibilidade do sitio. Nun agradable venres á noite de verán, o sitio web dunha coñecida tenda en liña de Moscova estaba tranquilo. O sábado pola mañá, o xestor de produtos deste sitio non entendía por que non se abría o sitio e houbo silencio nos chats de soporte e notificacións urxentes en Slack. Tal erro custounos unha suma de seis cifras, e este oficial de servizo o seu traballo.
A responsabilidade é unha habilidade difícil de desenvolver. Ten unha persoa ou non. Por iso, durante as entrevistas, intento identificar a súa presenza con diversas preguntas que indican indirectamente se unha persoa está afeita a asumir a responsabilidade. Se unha persoa responde que elixiu unha universidade porque o dixeron os seus pais ou cambia de traballo porque a súa muller dixo que non gaña o suficiente, entón é mellor non involucrarse con esa xente.
Interacción co equipo de desenvolvemento
Cando os usuarios atopan problemas sinxelos cun produto durante o seu funcionamento, o soporte resolve por si mesmo. Tenta reproducir o problema, analiza os rexistros, etc. Pero que facer cando aparece un erro no produto? Neste caso, o soporte asigna a tarefa aos desenvolvedores e aquí é onde comeza a diversión.
Os desenvolvedores están constantemente sobrecargados. Están creando novas funcións. Corrixir erros coas vendas non é a actividade máis interesante. Achéganse os prazos para completar o próximo sprint. E entón chegan persoas desagradables do apoio e din: "Deixa de todo inmediatamente, temos problemas". A prioridade deste tipo de tarefas é mínima. Especialmente cando o problema non é o máis crítico e a funcionalidade principal do sitio funciona, e cando o xestor de versións non corre cos ollos saltones e escribe: "Engade urxentemente esta tarefa á seguinte versión ou revisión".
Os problemas con prioridade normal ou baixa móvense dunha versión a outra. Á pregunta "Cando se completará a tarefa?" recibirás respostas do estilo de: "Sentímolo, hai moitas tarefas neste momento, pregúntalle aos líderes do teu equipo ou ao xestor de versións".
Os problemas de produtividade teñen maior prioridade que a creación de novas funcións. As malas críticas non tardarán en chegar se os usuarios tropezan constantemente con erros. Unha reputación danada é difícil de restaurar.
Os problemas de interacción entre desenvolvemento e soporte son resoltos por DevOps. Esta abreviatura utilízase a miúdo baixo a forma dunha persoa específica que axuda a crear ambientes de proba para o desenvolvemento, constrúe pipelines CICD e leva rapidamente o código probado á produción. DevOps é un enfoque para o desenvolvemento de software cando todos os participantes no proceso interactúan estreitamente entre eles e axudan a crear e actualizar rapidamente produtos e servizos de software. Refírome a analistas, desenvolvedores, probadores e soporte.
Neste enfoque, o apoio e o desenvolvemento non son departamentos diferentes con metas e obxectivos propios. O desenvolvemento está implicado na operación e viceversa. A famosa frase dos equipos distribuídos: "O problema non está do meu lado" xa non aparece tantas veces nos chats e os usuarios finais fanse un pouco máis felices.
Fonte: www.habr.com