Mejoran DevOps ingeniero habilidades blandas, se puede ver en un artículo antes de "DevOps ingenieros requieren habilidades blandas"
"Proyecto Fénix" es la comunidad de Dios DevOps libro, aunque el contenido es una forma de ficción, pero aún así el desarrollo ágil y DevOps en el campo de la lectura de libros. Muchos consultores conocidos son abiertas por este libro DevOps y ágil historia de viaje en el libro se derivan de la operación y el mantenimiento del trabajo diario, es una manifestación del arte de la vida, que la esencia de la vida. El intervalo autor de dos años, leyó el libro dos veces, espero que puede hablar un poco de experiencia en el libro aprendido a los demás.
Bill protagonista, temporalmente se hizo cargo de la situación de los gerentes de operaciones de TI, sin embargo esta vez, la empresa ha pasado por varias rondas de despidos, fallo en la línea de producción constante. La Junta espera que Phoenix para reiniciar el proyecto para salvar la empresa, pero las capas de las dificultades que enfrentan, Bill comenzó a dejar de hacer frente a la línea de falla repentina, física y mentalmente fatigado. Con el fin de sobrevivir y el funcionamiento normal de la empresa, trate de un conjunto para el programa de transformación de TI de la empresa, todo el proceso es como DevOps transformación del modo de desarrollo, ya que la transición desde el modo tradicional de desarrollo, entramos en una gran cantidad de pozos, resumió mucho sentido, el contenido de la novela yo sólo tenía narrativa y más, para entender las historias maravillosas pueden ir directamente a la compra de libros, lo siguiente será dar a resumir algunas de las lecciones importantes del libro.
1. forma de trabajo de cuatro
En la historia, el héroe Bill éxito en el administrador de TI, a través de una serie de solución de problemas y el proceso de comunicación interpersonal, llegamos a esta conclusión. trabajo que es no es más que los siguientes cuatro tipos:
- Proyectos de TI dentro del departamento
- proyecto de grupo de negocios
- cambio de trabajo
- los esfuerzos de lucha contra incendios
De hecho, los anteriores cuatro tipos de trabajo es coherente con el estado actual de nuestros departamentos de operaciones y mantenimiento, tenemos que desarrollar su propio funcionamiento y el mantenimiento y la vigilancia de la plataforma, para participar en el desarrollo y negocio de pruebas, deberíamos ser todos los cambios y mejoras a la infraestructura y la versión de aplicaciones . Y estos son parte del trabajo normal, que a menudo son los más reacios a tratar es las operaciones de extinción de incendios, todas las funciones de usuario, tales como la línea que conduce al fallo repentino no se pueden utilizar, a menudo en el personal de operación y mantenimiento técnico será vicepresidente, director de tecnología, CEO de incluso viendo la siguiente línea golpeó la línea de comandos, solucionar el problema. Un gran número de personal de operación y mantenimiento debería haber tenido una experiencia similar, en retrospectiva, debe haber sido terrible, así que tenemos que trabajar para reducir este fuego, y los tres primeros asignación racional de trabajo.
2. Fortalecer la gestión del cambio, reducir el comportamiento del fuego
A partir de las cuatro de la forma de trabajo de TI, salimos de un problema, la manera de reducir el comportamiento del fuego, vamos a ver la operación y mantenimiento de dos círculos leyes
La famosa ley de ocho: el 80% de la línea de fallo desde el 20% del cambio.
La teoría GoogleSRE: aproximadamente el 70% de los accidentes por el despliegue de algún tipo de cambio se dispara
Nosotros no se enreden 80% y el 70% de la diferencia es cómo producir, pero la conclusión es la unidad, un gran número de líneas de fallas se deben a cambios resultan de los cambios incluyendo aplicaciones, bases de datos, sistemas operativos de red o hardware operativo físico, lógico o virtual. Podemos ver, el contenido cubre una gran cantidad de operación y mantenimiento, razón por la fácil operación y mantenimiento cabeza de turco, que se debe a que por lo general estos cambios para hacer frente a operaciones de alto riesgo, que pueden provocar un fallo en la línea. El extraños, operación y mantenimiento está en problemas, después del inicio de las operaciones de lucha contra incendios, la solución de problemas. Con el fin de evitar el tipo de situación, cómo manejarlo? El artículo nos da un método muy importante es usar el método Kanban, la gestión normalizada de todos los cambios, los cambios previstos una vez cada, cada cambio trae punto de evaluación de riesgos, incluso si se produce un fallo, se puede reparar rápidamente.
3. El fortalecimiento de las reservas técnicas, evitar heroísmo personal
Cuando resolver todos los cambios causados por el fracaso de la novela, no era una persona importante, Du Lunte, este es un papel heroico en el equipo de operación y mantenimiento, que no resuelve el problema. Pero es una persona tan poderosa, al igual que todos los desarrolladores están buscando para él hacer cambios, todos los fallos del sistema tienen que tratar con él, hasta el punto de que las personas que se dedican a la labor de lucha contra incendios todos los días. Este papel se convierte en un punto de cuello de botella que enviamos proceso de normalización dimensional. Mientras que su trabajo no puede ser reemplazado por otras personas, no podemos dejar que lo haga el equipo de operación y mantenimiento cosas más importantes, como la automatización de edificios, tales como el seguimiento de la construcción de vital importancia. La novela Para resolver este problema, Bill creó un mecanismo de clasificación de resolución de problemas, el Du Lunte protegida, no permite a los desarrolladores para comunicarse directamente con Du Lunte, y ponerle en contacto con otros ingenieros Du Lunte trabajo original, de Du permiten Lunte centrarse en la automatización de edificios y el seguimiento de la construcción. Tal aumento de la posición clave en las reservas técnicas, sino también el personal técnico básico utilizado en la posición más importante.
4. número limitado de productos, hacer a partir de 0 a 1, reduciendo el número de (Kanban) 0,5
El nombre de la novela llamada "Proyecto Fénix", la gira en la historia de todo el núcleo del proyecto Phoenix, el proyecto Phoenix es un programa de tres años, después de tres años de apenas contener el gran movimiento de un proyecto en la línea, por supuesto, preparado durante tanto tiempo por último, el proyecto terminó en un fracaso, la cuestión de lo que nos dice. piso de la fábrica héroe para darse cuenta de que si se fija la mano de obra de fábrica, si los productos semi-acabados acumulan demasiado, que dará lugar al producto final entregado al cliente se ralentizará, que es lo que se decía en el campo de desarrollo de software afecta a la WIP la velocidad de entrega, si el equipo de desarrollo iterativo, al mismo tiempo demasiada demanda, entonces no debe ser entregado en manos del usuario necesidades para extender el tiempo. Por lo tanto limitar el número de productos es un elemento central de DevOps construcción, que deberíamos hacer el 0-1 cosa, y reducir el número de 0,5. El libro resume muy bien, una vez bloqueado en forma de productos semiacabados de capital de más de un año de I + D sin la devolución de efectivo de la empresa, que es casi imposible de pagar para la empresa.
El método de tres pasos de trabajo
Por último, las sumas de autor hasta el nuevo método de trabajo de tres etapas, que comprende:
1) principio de flujo
Principio de flujo es DevOps infraestructura y acortar el tiempo para satisfacer las necesidades de los clientes potenciales, cadena de herramientas de automatización de construcción, reduciendo proceso de intervención manual, reducir el número de productos, iteración rápida, puede mejorar efectivamente la calidad del trabajo y la productividad.
2) Principio de retroalimentación
Encontrado el problema en la fuente, encontrar problemas a tiempo, poniendo a prueba la seguridad y la izquierda, en la fuente de la producción es necesaria para garantizar la calidad.
3) el aprendizaje continuo y principios experimentales
La productividad, el flujo de trabajo se elevan hacia el liderazgo, para promover la cultura DevOps aterrizaje.
Resumen: ¿Qué estás esperando, los libros de compra para verlo, "Proyecto Fénix".
Más emocionante contenido a centrar nuestra aula en línea
Buscar número público de micro-canales: jfrogchina obtener notificaciones del curso