Citymobil: una guía para nuevas empresas para aumentar la estabilidad en medio del crecimiento. Parte 1



Con este art√≠culo, abro un ciclo corto de dos art√≠culos en el que describir√© en detalle c√≥mo logramos aumentar la estabilidad de los servicios de Citymobil varias veces durante varios meses. El art√≠culo comienza con una historia sobre nuestro negocio, sobre la tarea, sobre la raz√≥n de la aparici√≥n del problema del aumento de la estabilidad y sobre las limitaciones. Citymobil es un agregador de taxis de r√°pido crecimiento. En 2018, creci√≥ m√°s de 15 veces en el n√ļmero de viajes exitosos. En algunos meses, el crecimiento super√≥ el 50% en comparaci√≥n con el mes anterior.

El negocio creci√≥ a pasos agigantados (y sigue creciendo): la carga en los servidores, el tama√Īo del equipo y la frecuencia de despliegues han aumentado. Junto con esto, aparecieron nuevas amenazas a la estabilidad del servicio. La compa√Ī√≠a enfrent√≥ la tarea m√°s importante: no detener el crecimiento del negocio para aumentar la estabilidad. En este art√≠culo, le contar√© c√≥mo logramos realizar esta tarea en poco tiempo.

1. Declaraci√≥n del problema: ¬Ņqu√© es exactamente lo que queremos mejorar?


Antes de mejorar algo, debe aprender a medirlo para comprender claramente si hay una mejora. Cuanto m√°s se acerque el valor medido a los t√©rminos favorables para los negocios, mejor. Porque cuanto mayor sea la probabilidad de que mejoremos lo que el negocio realmente necesita. Desde el punto de vista de su √©xito, el par√°metro m√°s importante para nosotros es el n√ļmero de viajes completados con √©xito (en adelante, brevemente, el n√ļmero de viajes). Es precisamente por este par√°metro que los inversores nos eval√ļan cuando toman una decisi√≥n sobre las inversiones. Cuantos m√°s viajes, m√°s costosa es la empresa.

Algunos viajes generan ganancias, otros, pérdidas. Pero todos los viajes son igualmente importantes para nosotros, incluso no rentables, porque nos permiten aumentar la participación en el mercado (de hecho, la pérdida en los viajes es una tarifa por aumentar la participación en el mercado). Por lo tanto, cada viaje adicional recibido es bueno y cada viaje perdido es malo. Todos los viajes son iguales en términos de éxito empresarial.

De aqu√≠ obtuvimos un criterio comprensible para medir la estabilidad: el n√ļmero de viajes perdidos son viajes que claramente perdimos debido a problemas t√©cnicos. Un problema t√©cnico significa, por ejemplo, un error en el c√≥digo, un error n√ļmero 500, un bloqueo en la infraestructura, una integraci√≥n interrumpida con un servicio asociado (por ejemplo, mapas de Google).

2. ¬ŅC√≥mo contar los viajes perdidos?


Los viajes perdidos son a veces f√°ciles de calcular, a veces dif√≠ciles. Por ejemplo, en el caso de una denegaci√≥n completa de servicio, cuando nada funciona (pah-pah-pah), es muy f√°cil calcular los viajes perdidos. Conocemos el gr√°fico de tendencia del n√ļmero de viajes antes de la ca√≠da, vemos la tendencia de este gr√°fico despu√©s de la ca√≠da, completamos la l√≠nea entre el punto cuando comenz√≥ simple y el punto cuando termin√≥. El √°rea del gr√°fico del n√ļmero de viajes bajo esta l√≠nea completa es viajes perdidos.

En el siguiente gr√°fico, la l√≠nea negra muestra viajes en un d√≠a determinado y la l√≠nea verde muestra viajes hace una semana. El eje X es el tiempo. En el eje Y, el n√ļmero de viajes en un cierto intervalo de tiempo alrededor del punto X. Un pico claro se ve hacia abajo en forma de un tri√°ngulo de √°ngulo agudo. El √°rea de este tri√°ngulo es el n√ļmero de viajes perdidos. Por supuesto, esta es una cantidad aproximada, porque el gr√°fico es fluctuante, pero entendemos que incluso una precisi√≥n del 10-20% es suficiente para que podamos estimar la escala del accidente para un negocio.



Si simple no es completo, sino parcial (tambi√©n, pah-pah-pah), entonces el c√°lculo es un poco m√°s complicado. Por ejemplo, si hay un error debido al cual el 10% de los pedidos nunca se distribuyen en autom√≥vil, entonces vemos una falla en el horario de viaje y luego un rebote (despu√©s de corregir el error). En una situaci√≥n similar, los viajes perdidos son el √°rea limitada por la l√≠nea de tendencia; desde abajo, el horario real del n√ļmero de viajes, a la izquierda, la l√≠nea vertical del comienzo del tiempo de inactividad, a la derecha, la l√≠nea vertical del final del tiempo de inactividad.

El gráfico a continuación muestra que el pico más bajo no es tan obvio, pero la presencia de viajes durante la semana anterior sin un pico más bajo ayuda a comprender que un pico más bajo es una pérdida. Además, una comparación de los viajes para el día actual y el mismo día de la semana a la semana anterior deja en claro que el pico más a la derecha no son los viajes perdidos, sino un fracaso habitual en este momento del día, porque se correlaciona con la semana anterior.



Por lo general, es dif√≠cil construir una l√≠nea de tendencia, porque El gr√°fico de diente de sierra. En este caso, la comparaci√≥n semana a semana nos ayuda. Si dibuja dos l√≠neas en el mismo gr√°fico, la √ļltima semana y la actual, entonces resulta que ambas curvas m√°s o menos tienen una forma similar, pero solo difieren en que una est√° por encima de la otra (la semana actual habitual es m√°s alta que la anterior, aunque hay excepciones). La comparaci√≥n de semana a semana es importante, porque cada d√≠a de la semana, debido a diferentes circunstancias, tiene un formulario de horario diferente. Mirando el gr√°fico de semana a semana, puede comprender d√≥nde podr√≠a estar la l√≠nea de tendencia de los viajes de hoy.

Obviamente, un viaje perdido en sí mismo es un problema mucho mayor que un solo viaje perdido. Un cliente que quiere irse de una manera u otra se irá, por ejemplo, usará un servicio competitivo y posteriormente no podrá regresar a nosotros, o solo volverá cuando un competidor lo decepcione, lo cual es poco probable, porque Los competidores son muy fuertes. Además, incluso si un competidor decepciona al cliente, no es un hecho que regrese, porque todo se verá en su cabeza para que todos tengan un mal servicio, y no tiene sentido saltar sobre los competidores.

Es decir, un viaje perdido debido a problemas técnicos significa, de hecho, algunos viajes perdidos.

Para no confundirnos en términos, llamamos a los viajes perdidos directamente debido a un problema técnico, viajes perdidos primarios y viajes perdidos por dejar al competidor, viajes perdidos secundarios .

Idealmente, para calcular el da√Īo total a un negocio de un viaje perdido principal, debe comprender cu√°nto gener√≥ el viaje perdido secundario. Es decir es necesario multiplicar el n√ļmero de viajes perdidos iniciales por un cierto coeficiente K , que se puede calcular sobre la base de la frecuencia promedio de uso del servicio y el tiempo promedio de devoluci√≥n del usuario despu√©s de dejar al competidor.

Bajo el supuesto de que el coeficiente K no cambia mucho con el tiempo, para comprender la tendencia de la p√©rdida de viaje, es suficiente considerar los viajes perdidos primarios y tratar de reducir su n√ļmero, ya que la relaci√≥n de viajes perdidos primarios per√≠odo a per√≠odo ser√° la misma que la relaci√≥n de viajes perdidos secundarios per√≠odo a per√≠odo periodo Ejemplo: si perdimos 1000 viajes primarios el mes pasado, los viajes secundarios perdimos 1000 * K , y en total perdimos 1000 * (1+ K ). Si, adem√°s, en el mes actual perdimos 500 viajes primarios, luego los viajes secundarios perdimos 500 * K , y en total perdimos 500 * (1+ K ). En este caso, independientemente del valor del coeficiente K, comenzamos a perder viajes 1000 * (1+ K ) / (500 * (1+ K )) = 2 veces menos.

Incluso si el coeficiente K cambia con el tiempo, es decir es una funci√≥n del tiempo K (t), entonces todav√≠a estamos interesados ‚Äč‚Äčen reducir el n√ļmero de viajes perdidos primarios. Porque si K (t) crece con el tiempo, entonces estamos m√°s obligados a hacer esfuerzos para perder menos viajes primarios, porque el da√Īo de perder cada uno es mayor y mayor. Por otro lado, si K (t) disminuye con el tiempo, esto significa que, por alguna raz√≥n, los usuarios son cada vez m√°s leales a nosotros, a pesar del mal servicio, lo que significa que simplemente debemos cumplir sus expectativas.

Total: estamos luchando por una disminución constante en los viajes perdidos primarios.

3. Ok, consideramos los viajes perdidos. Que sigue


Armados con una herramienta comprensible para medir los viajes perdidos, pasamos a la parte m√°s interesante: ¬Ņc√≥mo hacerlo para reducir las p√©rdidas? Y aunque no frena el crecimiento actual! Dado que subjetivamente nos pareci√≥ que la mayor parte de los problemas t√©cnicos debido a los viajes que se pierden est√°n relacionados con el backend, decidimos ante todo prestar atenci√≥n al proceso de desarrollo del backend. Mirando hacia el futuro, dir√© que result√≥ de esa manera: el backend se ha convertido en el principal campo de batalla para los viajes perdidos.

4. Cómo funciona el proceso


Los problemas generalmente ocurren debido a la transferencia de código y otras acciones manuales. Los servicios que nunca cambian y nunca se tocan, a veces también fallan, pero esta excepción es solo una regla de confirmación.

La excepci√≥n m√°s divertida en mi experiencia fue el siguiente servicio. Cuando trabaj√© en RBC en 2006 (¬°Dios, qu√© edad tengo!), Luego, en uno de los servicios de correo de RBC hab√≠a una puerta de enlace a trav√©s de la cual pasaba todo el tr√°fico y que verificaba que las direcciones IP estuvieran en la lista negra. El servicio funcion√≥ en FreeBSD, y funcion√≥ correctamente. Pero un d√≠a, dej√≥ de trabajar. Adivina por qu√©? Un disco se derrumb√≥ en esta m√°quina (bloques defectuosos acumulados, acumulados y acumulados). Se derrumb√≥ 3 a√Īos antes de la denegaci√≥n de servicio en el servicio (!). Y todo viv√≠a con un disco disperso. Y luego el "frach", por cualquier motivo desconocido para ella por los motivos de Phryakhov, decidi√≥ recurrir repentinamente a un disco desmoronado y finalmente congelarse. Estoy seguro de que Linux no har√≠a eso. Pero este es un holivar separado.

Para resumir lo anterior, los problemas se deben a la intervenci√≥n manual. Una vez en mi infancia, a la edad de 10-12 a√Īos, en uno de mis viajes al bosque, escuch√© de mi padre una frase que record√© toda la vida: "para que la fogata no se apague, simplemente no es necesario tocarla". Creo que muchos de nosotros recordamos los momentos en que arrojamos le√Īa a un fuego que ya ard√≠a y se apag√≥ por alguna raz√≥n desconocida.

El resultado final: los problemas se crean mediante acciones manuales de una persona, por ejemplo, arrojar le√Īa a un fuego que ya arde bien, que corta el ox√≠geno y extingue un fuego, o al extender el c√≥digo con errores en la producci√≥n. Por lo tanto, para comprender la causa de los problemas en los servicios, debe comprender exactamente c√≥mo ocurre el despliegue y c√≥mo funciona el proceso de desarrollo.

El proceso se centró completamente en el desarrollo rápido y se organizó de la siguiente manera:

  • 20-30 lanzamientos por d√≠a;
  • los desarrolladores se implementan ellos mismos;
  • prueba r√°pida en un entorno de prueba por parte del desarrollador;
  • pruebas m√≠nimas automatizadas / unitarias, revisiones m√≠nimas.

Los desarrolladores en las condiciones m√°s dif√≠ciles, de hecho, sin √°reas traseras cubiertas frente al control de calidad, con una gran cantidad de tareas productivas y experimentos importantes para los negocios, trabajaron lo m√°s enfocado y coordinado posible, resolvieron problemas complejos de manera simple, no permitieron que el c√≥digo "creciera", entendieron bien los problemas comerciales , muy responsablemente a los cambios, retrocedi√≥ r√°pidamente el inactivo. Citymobil no es √ļnico aqu√≠. Hace 8 a√Īos en Mail.ru Mail, cuando vine a trabajar all√≠, hab√≠a una situaci√≥n similar. Y tambi√©n comenzamos Mail.ru Cloud de forma r√°pida y sencilla, sin reverencias. Y ya posteriormente cambiaron los procesos para lograr una mayor estabilidad.

Seguramente, lo notaste por tu cuenta: cuando nadie te cubre la espalda, cuando solo est√°s solo con la producci√≥n, cuando se aplasta una enorme carga de responsabilidad, haces milagros. Yo mismo tuve tal experiencia (a√ļn m√°s hardcore). √Črase una vez, en el siglo pasado (estimaci√≥n, Internet ya estaba en el siglo pasado, me sorprende cuando lo recuerdo), trabaj√© como el √ļnico desarrollador del servicio de correo newmail.ru, lo implement√© yo mismo y tambi√©n prob√© la producci√≥n. a ti mismo a trav√©s de if (!strcmp(username, ‚Äúdanikin‚ÄĚ)) { ‚Ķ some new code‚Ķ } :-) Por lo tanto, esta situaci√≥n est√° cerca de m√≠.

No me sorprendió si supiera que con un enfoque tan simple "sobre la rodilla" comenzaron muchas startups, tanto exitosas como infructuosas, pero impulsadas por la misma pasión: centrarse en el rápido crecimiento del negocio y la captura del mercado.

¬ŅPor qu√© fue el proceso espec√≠ficamente en Citymobil? Inicialmente, hab√≠a pocos desarrolladores. Trabajaron en la empresa durante mucho tiempo y ten√≠an una buena comprensi√≥n del c√≥digo y los negocios. Los lanzamientos fueron varias veces al d√≠a. Los errores fueron extremadamente raros. El proceso funcion√≥ perfectamente para esas condiciones.

5. ¬ŅPor qu√© un buen proceso amenaz√≥ la estabilidad?


Con la creciente inversi√≥n en el proyecto, hicimos nuestros planes de productos m√°s agresivos y comenzamos a contratar a muchos desarrolladores. El n√ļmero de lanzamientos en la producci√≥n aument√≥, pero se esperaba que su calidad cayera, porque los nuevos muchachos profundizaron en el sistema y la esencia del negocio en condiciones de combate. Con un aumento en el n√ļmero de desarrolladores, la estabilidad comenz√≥ a caer no solo linealmente, sino de forma cuadr√°tica (el n√ļmero de implementaciones creci√≥ linealmente, y la calidad del despliegue promedio tambi√©n cay√≥ linealmente; "linealmente" * "linealmente" == "cuadr√°ticamente").

Era obvio que era imposible dejar el proceso de esta forma. Simplemente no fue encarcelado bajo nuevas condiciones. Pero fue necesario cambiarlo sin perjuicio del tiempo de comercializaci√≥n, es decir, con la preservaci√≥n de 20-30 lanzamientos por d√≠a (y con un aumento en su n√ļmero en proporci√≥n al tama√Īo del equipo). De hecho, fue en un gran n√ļmero de lanzamientos que se hizo todo el punto. Crecimos r√°pidamente, establecimos muchos experimentos, evaluamos r√°pidamente sus resultados y establecimos nuevos experimentos. Probamos r√°pidamente hip√≥tesis de productos y negocios, las estudiamos y presentamos nuevas hip√≥tesis, que nuevamente probamos r√°pidamente, etc. No quer√≠amos reducir este ritmo en ning√ļn caso. Adem√°s, quer√≠an aumentarlo y aumentar la velocidad de contrataci√≥n de desarrolladores. Es decir nuestras acciones dirigidas al crecimiento empresarial crearon una amenaza para la estabilidad, pero no quer√≠amos corregir estas acciones de ninguna manera.

6. Ok, la tarea est√° clara, el proceso est√° claro. Que sigue


Con experiencia en Mail.ru Mail y Mail.ru Cloud, donde la estabilidad desde alg√ļn punto se puso a la vanguardia, donde los despliegues una vez por semana, la funcionalidad detallada y los casos de prueba descritos en detalle, todo est√° cubierto con pruebas autom√°ticas y unitarias, el c√≥digo se revisa al menos una vez y, a veces, tres veces, me encontr√© con una situaci√≥n completamente nueva.

Parece que todo es simple: repita el proceso en Citymobil como en Mail o la nube y aumente la estabilidad del servicio. Pero, como en esa broma obscena, hay matices: a) los despliegues en Mail / Cloud se llevan a cabo una vez por semana, y no 30 veces al día, y en Citymobil no queríamos sacrificar la frecuencia de los lanzamientos, b) en Mail / Cloud todo el código cubierto por pruebas automáticas / unitarias, y en Citymobil no teníamos tiempo ni recursos para esto, todas las fuerzas del desarrollo del backend fueron elegidas para probar hipótesis y mejoras de productos. Al mismo tiempo, no había suficientes desarrolladores de back-end, incluso a altas velocidades de contratación (gracias especiales a HR Citymobil: ¡estos son los mejores recursos humanos del mundo! Creo que habrá un artículo separado sobre nuestro proceso de recursos humanos), es decir, no había forma de participar en pruebas y revisiones estrictas sin frenar.

7. Cuando no sabes qué hacer, aprende de los errores


Entonces, ¬Ņqu√© hemos hecho m√°gicamente en Citymobil? Decidimos aprender de los errores. El m√©todo para mejorar el servicio a trav√©s del aprendizaje de los errores es tan antiguo como el mundo. Si el sistema funciona bien, entonces est√° bien. Si el sistema funciona con errores, entonces esto tambi√©n es bueno, porque puede aprender de estos errores. Eso suena facil. Hacer ... tambi√©n es simple. Lo principal es establecer una meta.

¬ŅC√≥mo estudiamos? Comenzamos registrando escrupulosamente la informaci√≥n sobre cada accidente mayor y menor. Francamente, inicialmente no quer√≠a hacer esto, porque esperaba un milagro y pens√© que los accidentes se detendr√≠an por s√≠ mismos. Por supuesto, nada se detuvo. Nuevas realidades exig√≠an despiadadamente el cambio.

Comenzamos a registrar todos los accidentes en una tabla com√ļn de Google. Para cada accidente, se proporcion√≥ la siguiente informaci√≥n breve:

  • fecha, hora, duraci√≥n;
  • causa ra√≠z
  • lo que hicieron para resolver el problema;
  • impacto en el negocio (n√ļmero de viajes perdidos, otros efectos);
  • conclusiones

Para accidentes grandes, creamos archivos grandes separados con descripciones detalladas minuto a minuto, desde el momento en que comenzó el accidente hasta el momento de su finalización: lo que hicimos, las decisiones que tomamos (por lo general, estas descripciones se llaman análisis post mortem). Y en la tabla general agregamos enlaces a dicha autopsia.

El propósito de este archivo era uno: sacar conclusiones, cuya implementación reducirá las pérdidas de viaje. Además, era muy importante formular con precisión cuál es la "causa raíz" y cuáles son las "conclusiones". Estas palabras son entendibles en sí mismas. Pero todos entienden a su manera.

8. Un ejemplo de un error en el que aprendieron


La causa raíz es la eliminación de la cual evitará accidentes similares en el futuro. Y las conclusiones son cómo eliminar la causa raíz (o reducir la probabilidad de que ocurra).

La causa raíz es siempre más profunda de lo que parece. Las conclusiones son siempre más complicadas de lo que parecen. Para no calmarse y detenerse en lo que parece ser, uno siempre debe estar insatisfecho con la causa raíz supuestamente encontrada y siempre estar insatisfecho con las conclusiones alegadas. Este descontento crea fervor para su posterior análisis.

D√©jame darte un ejemplo: desplegu√© el c√≥digo, todo cay√≥, retrocedi√≥, todo funcion√≥. ¬ŅCu√°l es la causa ra√≠z? Despliegue , usted dice. Si no fuera as√≠, no habr√≠a accidente. Entonces, ¬Ņcu√°l es la conclusi√≥n: no implementar? Mala conclusi√≥n (perjudicial para los negocios, para ser precisos). Es decir, lo m√°s probable es que esta no sea la causa ra√≠z, debe profundizar m√°s. Estirar con un error . ¬ŅLa causa ra√≠z? Digamos ¬ŅC√≥mo arreglarlo? Por pruebas, dices. Que pruebas Por ejemplo, una regresi√≥n completa de toda la funcionalidad. Esta es una buena conclusi√≥n, recu√©rdalo. Pero la estabilidad debe mejorarse aqu√≠ y ahora, mientras no haya una regresi√≥n completa. Necesito cavar a√ļn m√°s profundo. Despliegue con un error que ocurri√≥ debido al hecho de que depuramos la impresi√≥n en una tabla en la base de datos, la cargamos sin medida y la base de datos se rompi√≥ bajo carga . Esto ya es m√°s interesante. De inmediato queda claro que incluso una prueba de regresi√≥n completa no lo salvar√° de este problema. Despu√©s de todo, la base de prueba no tendr√° la misma carga que la producci√≥n.

¬ŅCu√°l es la causa ra√≠z de este problema, si profundiza a√ļn m√°s? Para averiguarlo, hablamos con el desarrollador. Result√≥ que estaba acostumbrado al hecho de que la base hace frente a las cargas. Pero en las condiciones del r√°pido crecimiento del proyecto, la base se manej√≥ ayer, pero hoy ya no est√° all√≠. Pocos de nosotros hemos trabajado en proyectos que est√°n creciendo al 50% de mes a mes. Por ejemplo, para m√≠ este es el primer proyecto de este tipo. Despu√©s de sumergirse en tal proyecto, comienza a darse cuenta de las nuevas realidades. Hasta la primera vez que te encuentres con algo, nunca sabr√°s lo que sucede.

El desarrollador sugiri√≥ inmediatamente la soluci√≥n correcta a la causa de la ca√≠da: depurar la impresi√≥n en un archivo, escribir el archivo fuera de l√≠nea por cron en la base de datos en una secuencia con resbalones. Si hay demasiada impresi√≥n de depuraci√≥n, entonces la base de datos no se acostar√°, solo la informaci√≥n de depuraci√≥n aparecer√° fuera de tiempo. Obviamente, este desarrollador ya aprendi√≥ de su error y no lo repetir√° en el futuro. Pero otros desarrolladores tambi√©n necesitan averiguar sobre esto. Como? Necesito decirles ¬ŅC√≥mo hacer que se escuche? Cu√©nteles toda la historia de principio a fin, explique a qu√© condujo e inmediatamente sugiera c√≥mo hacerlo, as√≠ como escuche sus preguntas y responda.

9. ¬ŅQu√© m√°s puedes aprender de este error, o qu√© hacer y qu√© no hacer?


Entonces, continuamos analizando este accidente. La compa√Ī√≠a est√° creciendo r√°pidamente, llegan nuevos empleados. ¬ŅC√≥mo van a aprender de este error? ¬ŅDecirle a cada nuevo empleado? Obviamente, habr√° m√°s y m√°s errores: ¬Ņc√≥mo hacer que todos aprendan de ellos? La respuesta es casi obvia: ¬°obtenga un archivo de qu√© hacer y qu√© no hacer (leer como "doos y donts")! En una traducci√≥n gratuita al ruso, lo que se debe y no se debe hacer significa "lo que es bueno y lo que es malo". En este archivo escribimos todas las conclusiones sobre el tema del desarrollo. Mostramos el archivo a todos los nuevos empleados, y tambi√©n lo mostramos en el chat general de los desarrolladores cada vez que se actualiza el archivo, y amablemente les pedimos a todos que lo lean nuevamente (para que podamos actualizar el conocimiento anterior y ver el nuevo).

Dir√°s que no todos leer√°n con cuidado. Dir√°s que muchos lo olvidar√°n inmediatamente despu√©s de leer. Y tendr√°s raz√≥n las dos veces. Pero no negar√°s que alguien tendr√° algo en la cabeza. Y esto ya est√° bien. Seg√ļn la experiencia de Citymobil, los desarrolladores toman muy en serio este archivo, y los casos en que se olvidaron algunas lecciones fueron extremadamente raros. Por cierto, el hecho mismo de que se olvid√≥ la lecci√≥n puede considerarse un problema y se puede sacar una conclusi√≥n, es decir, comprender los detalles y comprender c√≥mo cambiar el proceso para el futuro. Muy a menudo, tal excavaci√≥n conduce a una redacci√≥n m√°s precisa y clara en lo que se debe y no se debe hacer.

Conclusión del accidente descrito anteriormente: cree un archivo de qué hacer y qué no hacer, escriba lo que aprendió en él, muestre el archivo a todo el equipo y solicite a todos los recién llegados que lo estudien.

A partir del consejo general que entendimos en el an√°lisis de accidentes: no utilice la frase "factor humano". Tan pronto como diga esto, todos lo entienden de inmediato, de modo que no se necesita hacer nada, no se necesitan conclusiones, la gente estaba equivocada, equivocada y estar√° equivocada. Por lo tanto, en lugar de pronunciar esta frase, es necesario sacar una conclusi√≥n espec√≠fica . Conclusi√≥n: este es al menos un peque√Īo pero peque√Īo paso para cambiar el proceso, mejorar el monitoreo y mejorar las herramientas autom√°ticas. ¬°Con pasos tan peque√Īos se cose la estructura del servicio estable!

10. En lugar de un epílogo


En la segunda parte, le contaré sobre los tipos de accidentes de acuerdo con la experiencia de Citymobil y profundizaré en los detalles de cada tipo de accidente, así como también qué conclusiones sacamos de los accidentes, cómo cambiamos el proceso, que introdujo la automatización. ¡Lo más interesante en la segunda parte! Estén atentos!

Source: https://habr.com/ru/post/444818/


All Articles