Hace aproximadamente un año, se me planteó una tarea bastante seria: dar una conferencia de 2 horas para gerentes sobre la historia de Agile y DevOps.
Así comenzó mi regreso del avión softskill de entrenamiento ágil a TI. Y según los organizadores, más de 1000 gerentes de productos pasaron por esta conferencia, de los cuales aproximadamente 48/50 personas escucharon la palabra "Load Balancer" por primera vez en mi clase.
Incluso obtuve una deidad cómica "un gran equilibrador, maestro de actualizaciones sin tiempo de inactividad, barato para implementar pruebas A / B sin programación, y en general una buena noche de sueño de un gerente".
Por supuesto, los colegas de TI pueden reírse de esta simplificación e incluso indignarse de que el mundo no esté de acuerdo con la palabra "equilibrador" y cuánta atención se le puede prestar.
Pero cuando en mi gimnasio 48 personas de 50 no escucharon sobre el fenómeno del equilibrio de carga, es un poco triste. Sí, y los desarrolladores de los backends de algunas aplicaciones móviles, incluso los grandes bancos pueden pecar por la ausencia de tales esquemas.
Mi banco amarillo favorito, por ejemplo, actualiza el servidor back-end de una aplicación móvil a las 5 a.m., hora de Moscú, aproximadamente 2 veces por semana. ¿Por qué lo sé? Porque en Novosibirsk, donde volvía a vivir durante un año en 2016, ya eran las 9 de la mañana en ese momento, y el error 000 apareció para mí. Es terrible imaginar que esto ya es un almuerzo para el Lejano Oriente.
Tal vez tengamos la oportunidad de mejorar este mundo un poco si los gerentes piensan en la tolerancia a fallas al momento de presupuestar las capacidades del servidor, y no habrá 1 servidor para todo, sino un grado realmente proporcional de riesgo y configuración de carga del sistema.
Por qué
La primera pregunta que surge al establecer cualquier tarea, por supuesto: ¿por qué?
Existe tal marco:¿Por qué lo necesitamos? El | ¿Por qué lo necesitan?
¿Por qué lo necesitamos?
Si imaginamos que “nosotros” somos mucha gente de TI, no solo desarrolladores y especialistas relacionados, sino también consultores de tecnología, recursos humanos y entrenadores ágiles, que estamos en contacto diario con gerentes que no tienen experiencia en TI.
Por mi parte, respondí la primera pregunta de manera bastante simple: mejorar la educación técnica de los gerentes reduce en gran medida la probabilidad de tareas inadecuadas y aumenta la felicidad de los desarrolladores.
¿Por qué lo necesitan?
¿Por qué los gerentes que están realmente lejos de TI saben sobre esto?Todos somos personas y todos queremos dormir tranquilos. Los gerentes a menudo se responsabilizan de algo en lo que no pueden influir realmente. El nivel de estrés en este caso es comparable con los pasajeros de la aeronave que tienen aerofobia.
Y este es probablemente el único argumento que no será como el esnobismo "¿cómo no puedes saber cosas tan obvias?" O "cualquier persona debe vendar los ojos a una integral indefinida por la noche con los ojos vendados". En mi experiencia, si una persona está "al codo en la consola", entonces incluso inconscientemente, pero a menudo puede operar con tales sellos.
¿Cómo puedo explicar las imágenes simples complejas?
Las ilustraciones a continuación no afirman la verdad absoluta y no tienen un valor independiente, especialmente dado que estas simplificaciones no deben usarse como una guía de acción al construir arquitecturas tolerantes a fallas, ya que no tenía la intención de dibujar varios puntos sutiles, como el almacenamiento en caché, allí. Este es solo un modelo simplificado.
En el aprendizaje de adultos, y la asimilación de nueva información es parte del aprendizaje, es importante comprender que cualquier información debe repetirse al menos tres veces para aumentar la probabilidad de que realmente se obtenga.
Por ejemplo, un esquema de este tipo probablemente se asociará con el meme "no intentes abandonar Omsk" y solo confirma a la persona que piensa que "todo es complicado, pero también quieren muchos servidores".
Pero este esquema, que se muestra al principio, puede crear la asociación de una persona de la palabra "equilibrador" con el fenómeno de equilibrar la carga en el servidor. Sin ninguna garantía de una correcta comprensión de este proceso, pero con el conocimiento seguro de que existe y por qué es necesario.
Echemos a perder algunos puntos del
manifiesto Ágil en este lugar y digamos "es decir, sin disminuir el valor de lo que está a la derecha, valoramos más lo que está a la izquierda".
Por ejemplo, debido a que este esquema le permite comprender cómo configurar el sistema de prueba A / B sin escribir toneladas de código fuente, y cómo actualizar el servidor sin beber valor (al administrador, no al administrador) antes de eso.
Que sigue
Y esta misma comprensión abre el camino para el gerente al maravilloso mundo de CI / CD, porque si ya conocemos la mano de obra mínima requerida para hacer que la infraestructura sea parcialmente tolerante a fallas, tenemos menos miedo de las versiones frecuentes. Y esto cambia fundamentalmente el enfoque para actualizar las políticas en general.
Bueno, no me corresponde decirte que las ediciones más pequeñas se presentan a 1/10 de la capacidad (incluso si es 1 de cada 3 servidores, pero solo se le da el 10% del tráfico), esta es una fuerte disminución de las pasiones durante la actualización. Incluso si los servidores dejan de procesar por completo cada décima solicitud.
Una vez tuvimos una caída del 20% en RPS 600, y se eliminó rápidamente, parece incluso sin la participación de las personas. Fue entonces cuando yo, como PM técnico, responsable de todos los backends de la dirección, prácticamente comencé a repetir de forma aspirante la palabra "equilibrador" a otros gerentes.
Como lo demuestra mi experiencia, este conocimiento es extremadamente útil precisamente para que los gerentes puedan entender cómo minimizar los riesgos del lanzamiento e interesarse en CI / CD y varios experimentos tecnológicos.
Hace aproximadamente 4 años, aproximadamente la misma historia en mi práctica era contarles a los desarrolladores acerca de los sistemas de "brunch" similares a GitFlow para estabilizar lanzamientos y moratorias en los commits en la rama de lanzamiento, admitidos a nivel de gancho, pero últimamente se ha vuelto cada vez menos y menos requerido.
En mi opinión, ahora es realmente importante aumentar la alfabetización técnica de los gerentes no técnicos. Absolutamente no necesariamente de esta manera, por supuesto.