El deber es un componente importante de la mayoría de las organizaciones modernas. Después de todo, a menudo sucede que el problema llega a las 3 a.m. ¿Pero quién debería estar de servicio? ¿Y cómo organizar este proceso para que tenga sentido?
Mire debajo del gato, allí Baruch Sadogursky (
@jbaruch ) y Leonid Igolnik (
@ligolnik ) cuentan una historia de horror sobre un desafortunado oficial de servicio. ¿Recuerdas a Vasya, que siempre tenía que
arreglar los errores a las tres de la mañana? Esto es solo el comienzo.
El material fue preparado en base al discurso de Baruch y Leonid en la conferencia de otoño DevOops 2017.
Entonces de turno. Como ejemplo, tome el hipotético Vasya, que ha estado trabajando en una determinada empresa no hace mucho tiempo, aproximadamente un año. Hoy es viernes y sucedió que Vasya está de servicio. Todo va bien: Vasya está durmiendo y sus sueños son hermosos.
Si bien no sospecha nada, su colega de soporte técnico recibe una llamada de un cliente. Él dice que el lunes tendrá que mostrarle al CEO una demostración muy importante, pero algo no funciona. Necesidad urgente de solucionar el problema. El soporte hizo todo lo que pudo (sugirió apagarlo y encenderlo) y le pasa este problema al asistente.
Vasya está de servicio solo durante todo el proyecto, tendrá que hacer esto. Un ingeniero de soporte técnico lo despierta y trata de explicar el problema con palabras muy simples: "Algo no funciona allí, algo está mal".
Vasya escucha a su colega, reflexiona sobre lo sucedido y toma la única decisión correcta ...
El ingeniero de soporte se ofende, pero aún así le pide al cliente que espere hasta el lunes. El cliente no está de acuerdo con este estado de cosas y eleva el problema al gerente de soporte. Ahora llama a Vasya y dice que esto no es serio: "Aún así, el asunto es importante, el cliente está preocupado, es necesario". Vasya es una persona responsable. Debe ser necesario: café y baile (busque algo en los registros).
En los registros, todo resultó estar lejos de ser simple. Primero, Vasya buscaba a una persona con acceso al registro correcto durante 15 minutos. Lo encontró y consiguió un registro. Pero como? Para enviar por correo en formato .doc, por supuesto. Vasya es responsable, joven y lee el registro en Word: nada se entiende en absoluto. Pero hay palabras clave que puede buscar en la Base de conocimiento. Vasya se cuelga de cosas interesantes durante unos 20 minutos, aprende mucho de todo lo interesante, pero no se necesita nada por el momento.
¿Qué hace Vasya a continuación? Necesitas buscar a alguien, pero Vasya es un joven ingeniero y da miedo despertar a Senior. Por lo tanto, decide que debe llamar a un colega, el mismo joven.
Un colega es un buen amigo, con la pena a la mitad, entienden cuál es el problema y comienzan a resolverlo. Después de dos o tres horas de trabajo, encontraron una solución. Debe entregarse inmediatamente a la producción. Pero como? Hay un panel de control de cambios que se reúne los lunes una vez cada dos semanas. Pero esta opción no encaja, la necesita con urgencia.
Naturalmente, no se puede implementar en producción, no hay raíz. Entonces, la única opción es enviar un archivo jar con dos clases y un párrafo de explicaciones por correo electrónico. Esos tipos entrarán en producción a través de ssh y allí colocarán este archivo jar en WebSphere en el directorio correcto. Y ahora, a las 6-7 de la mañana, finalmente puedes irte a la cama con una sensación de logro.
El lunes, Vasya viene a trabajar y ve una imagen inusual. El CEO le gritaba al vicepresidente de ingeniería porque el cliente le gritaba al CEO porque su CEO le gritaba. Resulta que no fue posible resolver el problema.
Las autoridades tienen cuatro preguntas: "¿Qué pasó el viernes?"; "¿Por qué escuché esto del jefe el lunes?"; "¿Por qué la solución tardó seis horas?" y "¿Quién tiene la culpa?" Ops son llamados a la sala, quienes dicen que este no es su problema. Vasya y la otra criada son llamados a la habitación, quien también dice: "Nada funcionó". Todo este juego de papas continúa hasta el almuerzo.
Como es hora de cenar, la decisión "OK, está rota por sí misma, nadie tiene la culpa". El final de la historia.
Organicemos un pequeño informe: repasemos esta pesadilla e intentemos dar respuestas a todas las preguntas.
¿Quién debería estar de servicio?
Los administradores de sistemas (o una palabra más de moda, SRE) pueden estar de servicio. Han estado haciendo esto durante varios años, tienen todo bien establecido. DBA puede estar de servicio, aquellos que se dedican a la mensajería pueden. Si tiene suerte, NOC (centro de operaciones de red) está de servicio, esto es cuando todos estos tipos se ponen en la misma habitación. Tienen runbooks que dicen qué hacer en una situación difícil.
Todo está claro con estos tipos, son profesionales de servicio. Pero, desafortunadamente, DevOps tiene la segunda parte de la ecuación, que realmente no quiere estar de servicio. ¿Cómo hacer la segunda parte? Sí, y si es necesario forzar, porque los profesionales deben ser conscientes de la importancia del deber.
Hay dos razones por las cuales las personas no quieren estar de servicio. Una es cuando es así:
Nadie quiere estar de guardia cuando todo está mal. La solución a este problema es bastante simple:
Necesitas escribir un buen código, todo es simple. Pero esto también necesita ser aprendido. Surge una nueva pregunta: "¿Cómo aprender?". Debes poner los dedos en el zócalo: #painisinstructional. El dolor ayuda.
El deber en sí mismo mejora la calidad del código. El mismo Vasya el lunes, muy probablemente, corregirá sus errores para no quedarse otra noche en busca de errores.
Barreras de servicio
Cuando está de servicio, hay algunas barreras que no deberían estar allí. Veamos el fiasco del viernes de Vasya. ¿Recuerdas cómo leía los registros en un documento de Word?
Todos amamos los productos de Microsoft, pero no se puede hacer eso en el mundo moderno. Hay cosas obvias sobre los registros que todos deberían entender.
El punto principal es la cantidad de herramientas que resuelven estos problemas: Logstash, Loggly, Sumo logic, Kibana. Necesitan ser utilizados.
Volviendo a la cuestión del acceso: ¿por qué no dar acceso al registro? La respuesta son datos confidenciales. Se prometió a los clientes proteger los datos de las fugas. Esto significa que los registros no se pueden mostrar a nadie o necesita usar sistemas con la funcionalidad de enmascaramiento de datos. Él mismo oculta datos personales y no se los muestra a una persona sin el nivel de acceso requerido. Todas las herramientas de análisis de registros actuales tienen esta funcionalidad.
Otra ventaja de estas herramientas es que se puede construir un "monitoreo para los pobres". Por ejemplo, en los registros, después de ver una cierta cantidad de errores (la cola está llena, etc.), puede desencadenar una alergia.
¿Quién determina la importancia del problema?
¿Cómo entender, ir al servicio de turno o correr urgentemente para solucionar el problema? ¿Quién designa la gravedad? ¿Quién decide qué tan crítico es el problema? Resuelve el soporte. Por qué Porque el apoyo tiene una visión del problema. Él sabe lo malo que es todo.
Además, hoy en día casi todas las empresas trabajan según el principio de "Entrega continua", por lo que todos los clientes reciben todas las funciones al mismo tiempo (y al mismo tiempo, errores). Supongamos que hay un error que para el cliente se ve como "Algo no funciona allí, está bien". Al mismo tiempo, el soporte técnico ve cientos de alertas sobre el problema, y esto obviamente es grave.
El cliente también participa en la determinación de la importancia del problema. Pero hay un problema: el cliente no siempre cree que su pequeño problema será reparado y le da la mayor importancia. La gravedad comienza a usarse como una herramienta de manipulación. Pero si la definición de gravedad se construye correctamente y el cliente comprende qué es SLA, esto generalmente no sucede. Este es un proceso de aprendizaje mutuo cuando los clientes comienzan a comprender qué es realmente muy importante y qué es simplemente importante.
Los clientes deben tener la oportunidad de mostrar importancia porque el fabricante del producto no siempre comprende el contexto del problema.
SLA: una garantía de respuesta y soluciones en un día, pero puede ser más rápido. Esto, nuevamente, depende del contexto.
Desafíos organizacionales
Vasya no entendió el problema hasta el final. Por supuesto, él acaba de despertarse, y un colega de soporte técnico también explicó mal. Se trata de una sola manera: un boleto. Un boleto es un número de referencia que dice de qué se trata. Esto es necesario para Vasya, porque en lugar de un teléfono, el soporte podría decirle a Vasya "Abra nuestro sistema de gestión de tickets y vea el número de ticket 42". Esto es necesario por varias razones. Primero, Vasya, en lugar de escuchar a un colega en un estado de sueño, se despertará, irá a leer un boleto y comprenderá lo importante que es esto. En segundo lugar, puede haber más de un problema.
Hay otra dificultad que afecta el panorama general: es necesario encontrar a Vasya. ¿Cómo sabe el apoyo que Vasya está de servicio hoy? ¿Qué pasa si él tampoco conoce a Vasya? Es importante que encuentres a la persona adecuada. La solución es la extensión virtual con varios prefijos para ingeniero, producción, etc. Bueno, u otros sistemas más sofisticados. Con esta solución, no tiene que adivinar dónde llamar en medio de la noche; todo cambia automáticamente.
Aún más conveniente es Escalation Chat en Slack, Telegram, Skype, en cualquier lugar. El título del chat es el número del mismo boleto. Toda comunicación en este boleto entre las personas adecuadas se realiza en esta sala de chat. Una de las características más útiles de un chatik de este tipo es que no necesita decirle nada a quienes se unen al trabajo después de un tiempo. Simplemente puede leer sobre las decisiones que ya se han tomado.
Bueno, un puente telefónico virtual, que se puede comparar con un lugar de reunión en caso de incendio: todos saben a dónde ir en caso de problemas. Por cierto, en sistemas modernos como Zoom o Bluejeans, toda la funcionalidad necesaria ya está incorporada.
Camino de escalada
Vasya tenía miedo de llamar al señor, porque son terribles. ¿Qué hacer con eso? Hablemos sobre el camino de escalada. Siempre debe saber quién y cuándo despertarse o despegar del trabajo. Esto debería estar perfectamente claro para todos: para el que se despierta y para el que se despierta. También necesita saber dónde llamar si la primera ruta no funcionó. Un buen camino de escalada llega hasta el CEO de la empresa.
Hay comunicaciones que deberían provenir del CEO. Debe ser consciente de los problemas críticos.
Gerente de recados
El siguiente puesto interesante es gerente de guardia. No tiene que ser un experto en tecnología y participar en la resolución de un problema. Primero, Vasya en medio de la noche no puede decirle al cliente nada útil. El gerente de turno puede ayudar en esta situación. Además, puede participar en la coordinación, gestión de proyectos en una situación difícil, gestión de recursos. Después de todo, el trabajo debe ir sin problemas.
Acceso a la producción
¿Debería darle acceso a Vasya a la producción? Después de todo, no todos son ingenieros brillantes, y hay ciertas cosas de las que no me gustaría aprender, los clientes se sentirán ofendidos. Esto se resuelve utilizando el proceso de implementación. Si el proceso está configurado correctamente, Vasya puede hacer clic en el botón, que como resultado, su código de producción se desactivará. Si tiene una tubería de entrega continua normal, lo más probable es que esto se pueda hacer automáticamente (todas las pruebas pasarán). De lo contrario, en muchas empresas la decisión la toma un ingeniero o gerente superior. Él revisa, evalúa el riesgo del código y toma una decisión.
E incluso antes de que apareciera la revisión, las herramientas documentadas para la resolución de problemas deberían estar involucradas. Uno de los problemas más comunes de servicio: comienza a pensar cómo activar la depuración o cambiar el nivel de los registros. Al mismo tiempo, no hay problema con todo lo demás. Es aconsejable tener soluciones documentadas para los problemas.
Cambio de deber
Ahora hablemos sobre el proceso del deber, que generalmente toma una semana. En algún momento es necesario cambiar. Para cambiar de manera eficiente, esto debe hacerse en un momento determinado. Es necesario planificar todo claramente y es deseable poder transferir efectivamente los problemas a la siguiente persona en servicio. En muchas empresas, esto se realiza como un rally estándar, o se crea una página en la que el asistente mantiene una pequeña revista.
Otros problemas
Hay varios otros problemas que deben abordarse. Una de ellas es la certificación de acceso a la producción. Es aconsejable realizar una certificación primaria para que una persona demuestre que comprende lo que es posible y lo que no.
¿Cómo traducirlo?
Pero, ¿cómo se puede llevar todo esto a la empresa? Debe comprender que esto llevará algún tiempo.
Necesitamos comenzar con los hombres mayores de guardia. Tienen experiencia y saben qué y cómo reparar. El señor tiene menos problemas: hay acceso a los registros, etc.
Es recomendable comenzar en un equipo pequeño. Si el equipo ya es grande, debe crear uno pequeño dentro de él. Además, cuando todo comienza a funcionar bien, puede avergonzar al resto.
Conclusiones
Pasamos a lo principal. A pesar de que los técnicos están enamorados de la tecnología, lo más importante no son los productos y tecnologías que se utilizan en la empresa, sino el sentimiento de la persona de turno "Estoy involucrado en el proceso de mejorar el producto" (o del deber en sí mismo). Muchas personas entienden que debe estar de servicio, pero desea ver mejoras. La gente debe ser consciente de que gracias a ellos y a sus mejoras, las cosas están mejorando.
PS
Queremos recomendar un libro llamado Drive. Este es un libro sobre la motivación de las personas que trabajan en profesiones como la nuestra. Esta motivación consta de tres componentes principales y (spoiler) ninguno de ellos es dinero.
Ya este domingo, Baruch y Leonid entregarán un informe "#DataDrivenDevOps" en DevOops 2018 en San Petersburgo. Vamos, habrá muchas cosas interesantes: aquí están los informes , aquí está John Willis , y aquí hay una fiesta con BoFs y karaoke . Esperando por ti!