Como evacuamos a quenda de servizo de Yandex

Como evacuamos a quenda de servizo de Yandex

Cando o traballo encaixa nun portátil e pódese realizar de forma autónoma doutras persoas, entón non hai ningún problema para moverse a un lugar remoto: abonda con quedar na casa pola mañá. Pero non todos teñen tanta sorte.

A quenda de servizo é un equipo de especialistas en dispoñibilidade de servizos (SRE). Inclúe administradores, desenvolvedores, xestores, así como un "panel de control" común de 26 paneis LCD de 55 polgadas cada un. A estabilidade dos servizos da empresa e a rapidez na resolución dos problemas dependen do traballo da quenda de servizo.

Hoxe Dmitry Melikov tal10n, o xefe da quenda de garda, falará de como en cuestión de días conseguiron transportar os equipos ata as súas casas e establecer novos procesos de traballo. Doulle a palabra.

- Cando tes unha oferta infinita de tempo, podes moverte cómodamente con calquera cousa a calquera lugar. Pero a rápida propagación do coronavirus púxonos en condicións completamente diferentes. Os empregados de Yandex foron dos primeiros en cambiar ao traballo remoto, mesmo antes da introdución do réxime de autoillamento. Aconteceu así. O xoves 12 de marzo pedíronme que avaliase a posibilidade de trasladar o traballo do equipo a casa. O venres 13 recomendábase pasar ao traballo remoto. Na noite do martes 17 de marzo xa estaba todo preparado para nós: os encargados traballaban na casa, trasladáronse os equipos, escribiuse o software que faltaba, reconfiguraron os procesos. E agora vouvos contar como o fixemos. Pero primeiro cómpre lembrar as tarefas que resolve o turno de traballo.

Quen somos

Yandex é unha gran empresa con centos de servizos. A estabilidade da busca, o asistente de voz e todos os demais produtos non depende só dos desenvolvedores. A fonte de alimentación pode estar interrompida no centro de datos. Un traballador durante a substitución do asfalto pode danar accidentalmente o cable óptico. Ou pode haber un aumento da actividade dos usuarios, o que requirirá unha reasignación urxente da capacidade. Ademais, todos vivimos nunha infraestrutura grande e complexa, e o lanzamento dun dos produtos pode provocar accidentalmente a degradación doutro.

26 paneis do noso espazo aberto son mil e medio de alertas e máis de cen gráficos e paneis dos nosos servizos. De feito, este é un enorme panel de diagnóstico. Un administrador de tarefas experimentado, ao ollar, comprende rapidamente o estado dos nodos importantes e pode establecer a dirección para investigar un problema tecnolóxico. Isto non significa que unha persoa deba mirar constantemente todos os dispositivos: a propia automatización chamará a atención enviando unha notificación á interface especial do oficial de servizo, pero sen un panel visual, a solución ao problema pode atrasarse.

Cando se producen problemas, o encargado primeiro avalía a súa prioridade. Despois illa o problema ou minimiza o seu impacto nos usuarios.

Hai varias formas estándar de illar un problema. Unha delas é a degradación dos servizos, cando o administrador de garda desactiva algunhas das funcións que menos perciben os usuarios. Isto permítelle reducir temporalmente a carga e descubrir o que pasou. Se hai un problema co centro de datos, o oficial de servizo contacta co equipo operativo, comprende o problema, controla o momento da súa solución e, se é necesario, conecta os equipos pertinentes.

Cando o administrador de garda non pode illar o problema que xurdiu debido ao lanzamento, infórmao ao equipo de servizo e os desenvolvedores buscan erros no novo código. Se non o conseguen, entón o administrador atrae desenvolvedores doutros produtos ou enxeñeiros para a dispoñibilidade de servizos.

Podo falar durante moito tempo de como está todo arranxado con nós, pero creo que xa transmitín a esencia. A quenda de servizo coordina o traballo de todos os servizos e controla os problemas globais. É importante que o administrador de garda teña un panel de diagnóstico diante dos seus ollos. É por iso que cando cambias ao traballo remoto, non podes simplemente levar e darlle a todos un portátil. Os gráficos e as alertas non caberán na pantalla. Que facer?

Idea

Na oficina, os dez administradores de servizo traballan por quendas no mesmo panel, que inclúe 26 monitores, dous ordenadores, catro tarxetas de vídeo NVIDIA Quadro NVS 810, dúas fontes de alimentación ininterrompidas montadas en rack e varios accesos independentes á rede. Necesitabamos asegurarnos de que todos teñan a oportunidade de traballar dende a casa. Simplemente non é posible montar unha parede deste tipo nun apartamento (a miña muller estará especialmente contenta con iso), polo que decidimos crear unha versión portátil que se poida levar e montar na casa.

Comezamos a experimentar coa configuración. Necesitabamos encaixar todos os dispositivos en menos pantallas, polo que o principal requisito para o monitor era unha alta densidade de píxeles. Dos monitores 4K dispoñibles no noso contorno, escollemos Lenovo P27u-10 para probas.

Dos portátiles, tomamos un MacBook Pro de 16 polgadas. Ten un subsistema de gráficos bastante potente, que é necesario para renderizar imaxes en varias pantallas 4K, e catro conectores universais tipo C. Podes preguntar: por que non o escritorio? Substituír un portátil por exactamente o mesmo do almacén é moito máis sinxelo e rápido que montar e configurar unha unidade de sistema idéntica. E si, pesa menos.

Agora era necesario entender cantos monitores podemos conectar realmente a un portátil. E o problema aquí non é o número de conectores, só poderiamos averiguarlo probando o sistema como un conxunto.

Como evacuamos a quenda de servizo de Yandex

Probas

Colocamos comodamente todos os gráficos e alertas en catro monitores e ata os conectamos a un portátil, pero atopamos un problema. A representación de 4 × 4K píxeles nos monitores conectados cargou a tarxeta de vídeo tanto que o portátil descargouse mesmo mentres se cargaba. Afortunadamente, o problema resolveuse coa axuda da estación de acoplamento Lenovo ThinkPad Thunderbolt 3 Dock Gen 2. Conseguimos conectar un monitor, alimentación e ata o teu rato e teclado favoritos á estación de acoplamento.

Pero de inmediato xurdiu outro problema: a GPU infló tanto que o portátil quedou en exceso, o que significa que a batería tamén se sobrequentou, que como resultado pasou ao modo de protección e deixou de facerse cargo. En xeral, este é un modo moi útil que protexe contra situacións perigosas. Nalgúns casos, o problema resolveuse coa axuda dun dispositivo de alta tecnoloxía: un bolígrafo colocado debaixo do portátil para mellorar a ventilación. Pero isto non axudou a todos, polo que tamén aumentamos a velocidade do ventilador estándar.

Había unha característica máis desagradable. Todos os gráficos e alertas deben colocarse nun lugar estritamente definido. Imaxina que estás pilotando un avión para aterrar, e despois os indicadores de velocidade, altímetros, variómetros, horizontes artificiais, compás e indicadores de posición comezan a cambiar de tamaño e saltar en diferentes lugares. Así que decidimos facer unha aplicación que nos axude con isto. Nunha noite, escribímolo en Electron.js, tomando un listo API para crear e xestionar fiestras. Engadimos un controlador de configuración e a súa actualización periódica, así como soporte para un número limitado de monitores. Un pouco máis tarde, engadiron soporte para diferentes configuracións.

Montaxe e entrega

Para o luns, os asistentes da mesa de axuda conseguiran para nós 40 monitores, dez portátiles e o mesmo número de estacións de acoplamento. Non sei como o fixeron, pero moitas grazas.

Como evacuamos a quenda de servizo de Yandex

Quedaba por entregar todo isto nos pisos dos administradores de garda. E estes son dez enderezos en diferentes partes de Moscova: sur, leste, centro e tamén Balashikha, que está a 45 quilómetros da oficina (por certo, tamén se engadiu máis tarde un interno de Serpukhov). Había que repartir dalgunha maneira todo isto entre as persoas, construír loxística.

Introducín todos os enderezos nos nosos Mapas, aínda hai a oportunidade de optimizar a ruta entre distintos puntos (utilicei a versión beta gratuíta da ferramenta para mensaxeiros). Dividimos o noso equipo en catro equipos independentes de dúas persoas, cada un recibiu o seu propio percorrido. O meu coche resultou ser o máis espazos, así que levei equipos para catro empregados á vez.

Como evacuamos a quenda de servizo de Yandex

Toda a entrega levou un récord de tres horas. Saímos da oficina o luns ás XNUMX. Á unha da mañá xa estaba na casa. Esa mesma noite fomos de servizo con equipos novos.

Cal é o resultado?

En lugar dunha consola de diagnóstico grande, recollemos dez relativamente portátiles no apartamento de cada oficial de servizo. Por suposto, aínda quedaban algunhas cousas por resolver. Por exemplo, antes tiñamos un teléfono "ferro" do oficial de servizo para as notificacións. Baixo as novas condicións, isto non funcionou, polo que creamos "teléfonos virtuais" para os que estaban de servizo (de feito, canles no messenger). Tamén houbo outros cambios. Pero o principal é que nun tempo récord conseguimos trasladar non só persoas, reducindo o risco da súa infección, senón todo o noso traballo desde casa sen prexudicar os procesos e a estabilidade do produto. Levamos un mes facendo isto.

A continuación atoparás fotos dos traballos reais dos nosos asistentes.

Como evacuamos a quenda de servizo de Yandex

Como evacuamos a quenda de servizo de Yandex

Como evacuamos a quenda de servizo de Yandex

Como evacuamos a quenda de servizo de Yandex

Como evacuamos a quenda de servizo de Yandex

Fonte: www.habr.com