La pregunta “cómo implementar Devops” existe desde hace años, pero no hay muchos materiales buenos. A veces eres víctima de anuncios de consultores no tan inteligentes que necesitan vender su tiempo, sin importar cómo. A veces son palabras vagas y extremadamente generales sobre cómo las naves de las megacorporaciones surcan las extensiones del universo. Surge la pregunta: ¿qué nos importa esto? Estimado autor, ¿puede formular claramente sus ideas en una lista?
Todo esto se debe al hecho de que no se ha acumulado mucha práctica real y comprensión del resultado de las transformaciones de la cultura de la empresa. Los cambios culturales son cosas a largo plazo, cuyos resultados no aparecerán en una semana o un mes. Necesitamos a alguien con la edad suficiente para haber visto cómo se construyeron y fracasaron las empresas a lo largo de los años.
Juan Willis - uno de los padres de DevOps. John tiene décadas de experiencia trabajando con una gran cantidad de empresas. Recientemente, John comenzó a notar patrones específicos que ocurren cuando trabaja con cada uno de ellos. Utilizando estos arquetipos, John guía a las empresas por el verdadero camino de la transformación de DevOps. Lea más sobre estos arquetipos en la traducción de su informe de la conferencia DevOops 2018.
Sobre el orador:
Más de 35 años en gestión de TI, participó en la creación del predecesor de OpenCloud en Canonical, participó en 10 startups, dos de las cuales fueron vendidas a Dell y Docker. Actualmente es Vicepresidente de DevOps y Prácticas Digitales en SJ Technologies.
La siguiente es la historia desde el punto de vista de Juan.
Mi nombre es John Willis y el lugar más fácil para encontrarme es Twitter. . Tengo el mismo alias en Gmail y GitHub. A Puedes encontrar grabaciones en vídeo de mis informes y presentaciones para ellos.
Tengo muchas reuniones con CIO de varias grandes empresas. Muy a menudo se quejan de que no entienden qué es DevOps y todos los que intentan explicárselo están hablando de algo diferente. Otra queja habitual es que DevOps no funciona, aunque parece que los directores están haciendo todo según les explican. Hablamos de grandes empresas que tienen más de cien años. Después de hablar con ellos, llegué a la conclusión de que para muchos problemas, no es la alta tecnología la más adecuada, sino soluciones de tecnología relativamente baja. Durante semanas hablé con gente de diferentes departamentos. Lo que veis en la primera foto del post es mi último proyecto, así quedó la habitación después de tres días de trabajo.
¿Qué es DevOps?
De hecho, si preguntas a 10 personas diferentes, te darán 10 respuestas diferentes. Pero aquí está lo interesante: las diez respuestas serán correctas. No hay ninguna respuesta incorrecta aquí. Estuve bastante metido en DevOps durante unos 10 años y fui el primer estadounidense en el primer DevOpsDay. No diré que sea más inteligente que todos los involucrados en DevOps, pero casi nadie ha dedicado tanto esfuerzo a ello. Creo que DevOps ocurre cuando el capital humano y la tecnología se unen. Muchas veces nos olvidamos de la dimensión humana, aunque hablamos mucho de todo tipo de culturas.
Ahora tenemos muchos datos, cinco años de investigación académica y pruebas de teorías a escala industrial. Lo que nos dicen estos estudios es que si se combinan algunos patrones de comportamiento en una cultura organizacional, se puede lograr una aceleración 2000 veces mayor. Esta aceleración va acompañada de una mejora igual en la estabilidad. Esta es una medida cuantitativa del beneficio que DevOps puede aportar a cualquier empresa. Hace un par de años estaba hablando de DevOps con el CEO de una empresa Fortune 5000. Cuando me estaba preparando para la presentación, estaba muy nervioso porque tenía que resumir mis años de experiencia en 5 minutos.
Al final di lo siguiente Definición de DevOps: Es un conjunto de prácticas y patrones que posibilitan la transformación del capital humano en capital organizacional de alto desempeño. Un ejemplo es la forma en que ha operado Toyota durante los últimos 50 o 60 años.
(De ahora en adelante, dichos diagramas no se proporcionan como material de referencia, sino como ilustraciones. Su contenido será diferente para cada nueva empresa. Sin embargo, la imagen se puede ver por separado y ampliada.
Una de las prácticas más exitosas es mapeo de la cadena de valor. Se han escrito varios buenos libros sobre esto, los más exitosos son los de Karen Martin. Pero durante el año pasado llegué a la conclusión de que incluso este enfoque es demasiado tecnológico. Ciertamente tiene muchas ventajas y lo he usado mucho. Pero cuando el director general pregunta por qué su empresa no puede cambiar a nuevos rieles, es demasiado pronto para hablar de mapeo del flujo de valor. Hay muchas preguntas mucho más fundamentales que primero deben responderse.
Creo que el error que cometen muchos de mis colegas es que simplemente le dan a la empresa una guía de cinco puntos y luego regresan seis meses después y ven qué pasó. Incluso un buen esquema como el mapeo del flujo de valor tiene, digamos, puntos ciegos. Después de cientos de entrevistas con directores de varias empresas, he desarrollado un patrón determinado que nos permite dividir el problema en sus componentes, y ahora discutiremos cada uno de estos componentes en orden. Antes de aplicar cualquier solución tecnológica, utilizo este patrón y, como resultado, todas mis paredes están cubiertas de diagramas. Recientemente estuve trabajando con un fondo mutuo y terminé con entre 100 y 150 planes de este tipo.
La mala cultura se come los buenos enfoques en el desayuno
La idea principal es la siguiente: ninguna cantidad de Lean, Agile, SAFE y DevOps ayudará si la cultura de la organización en sí es mala. Es como bucear a profundidades sin equipo de buceo o operar sin rayos X. En otras palabras, parafraseando a Drucker y Deming: una mala cultura organizacional devorará cualquier buen sistema sin ahogarse con él.
Para resolver este problema principal, debe seguir los siguientes pasos:
- Haga visible todo el trabajo: necesitas hacer visible todo el trabajo. No en el sentido de que necesariamente deba mostrarse en alguna pantalla, sino en el sentido de que debe ser observable.
- Sistemas Consolidados de Gestión del Trabajo: Es necesario consolidar los sistemas de gestión. En el problema del conocimiento “tribal” y el conocimiento institucional, en 9 de cada 10 casos el cuello de botella son las personas. En el libro el problema fue con una sola persona, Brent, que provocó que el proyecto se retrasara tres años. Y me encuentro con estos “Brents” por todas partes. Para resolver estos obstáculos, utilizo los siguientes dos elementos de nuestra lista.
- Metodología de la teoría de las restricciones: teoría de las Restricciones.
- Trucos de colaboración: trucos de colaboración.
- Toyota Kata (): No hablaré mucho del Toyota Kata. Si está interesado, en mi github. sobre casi cada uno de estos temas.
- Organización orientada al mercado: organización orientada al mercado.
- Auditores de desplazamiento a la izquierda: auditoría en las primeras etapas del ciclo.
Empiezo a trabajar con una organización de forma muy sencilla: voy a la empresa y hablo con los empleados. Como puede ver, no hay alta tecnología. Todo lo que necesitas es algo sobre lo que escribir. Reúno varios equipos en una sala y analizo lo que me dicen desde la perspectiva de mis 7 arquetipos. Y luego les doy un marcador y les pido que escriban en la pizarra todo lo que han dicho en voz alta hasta ahora. Normalmente en este tipo de reuniones hay una persona que anota todo, y en el mejor de los casos puede anotar el 10% de la discusión. Con mi método, esta cifra se puede elevar hasta aproximadamente el 40%.
(Esta ilustración se puede ver por separado )
Mi enfoque se basa en el trabajo de William Schneider. ). El enfoque se basa en la idea de que cualquier organización se puede dividir en cuatro cuadrados. Para mí, este esquema suele ser el resultado de trabajar con esos cientos de otros esquemas que surgen al analizar una organización. Supongamos que tenemos una organización con un alto nivel de control, pero con baja competencia. Esta es una opción extremadamente indeseable: cuando todos siguen la línea, pero nadie sabe qué hacer.
Una opción ligeramente mejor es aquella con un alto nivel de control y competencia. Si una empresa de este tipo es rentable, quizás no necesite DevOps. Es muy interesante trabajar con una empresa que tiene un alto nivel de control, poca competencia y cooperación, pero al mismo tiempo un alto nivel de cultura (cultivo). Esto significa que la empresa tiene mucha gente a la que le gusta trabajar allí y la rotación laboral es baja.
(Esta ilustración se puede ver por separado )
Me parece que los métodos con directrices rígidas acaban interfiriendo en el camino para alcanzar la verdad. En particular, en el mapeo del flujo de valor, existen muchas reglas sobre cómo se debe estructurar la información. En las primeras etapas del trabajo, de las que hablo ahora, nadie necesita estas reglas. Si una persona con un marcador en la mano describe la situación real de la empresa en la pizarra, esta es la mejor manera de comprender la situación. Esta información no llega a los directores. En este momento, es una estupidez interrumpir a una persona y decirle que dibujó incorrectamente algún tipo de flecha. En esta etapa, es mejor utilizar reglas simples, por ejemplo: se puede crear una abstracción de varios niveles simplemente usando marcadores de varios colores.
Repito, nada de alta tecnología. El marcador negro representa la realidad objetiva de cómo funciona todo. Con un marcador rojo, la gente marca lo que no le gusta del estado actual de las cosas. Es importante que esto lo escriban ellos, no yo. Cuando voy al CIO después de una reunión, no le ofrezco una lista de 10 cosas que deben solucionarse. Me esfuerzo por encontrar conexiones entre lo que dice la gente de la empresa y los patrones comprobados existentes. Finalmente, un marcador azul sugiere posibles soluciones al problema.
(Esta ilustración se puede ver por separado )
Un ejemplo de este enfoque se muestra ahora arriba. A principios de este año trabajé con un banco. El personal de seguridad estaba convencido de que no debían acudir a revisiones de diseño y requisitos.
(Esta ilustración se puede ver por separado )
Y luego hablamos con gente de otros departamentos y resultó que hace unos 8 años, los desarrolladores de software despidieron a los trabajadores de seguridad porque estaban ralentizando el trabajo. Y luego se convirtió en una prohibición que se dio por sentada. Aunque en realidad no hubo ninguna prohibición.
Nuestra reunión se desarrolló de una manera extremadamente confusa: durante aproximadamente tres horas, cinco equipos diferentes no pudieron explicarme lo que estaba sucediendo entre el código y el ensamblaje. Y esto parecería ser lo más sencillo. La mayoría de los consultores de DevOps asumen desde el principio que todo el mundo ya lo sabe.
Entonces, el responsable del gobierno de TI, que había estado en silencio durante cuatro horas, de repente volvió a la vida cuando llegamos a su tema y nos ocupó durante mucho tiempo. Al final le pregunté qué pensaba del encuentro y nunca olvidaré su respuesta. Dijo: "Solía pensar que nuestro banco sólo tenía dos formas de entregar software, pero ahora sé que hay cinco y ni siquiera conocía tres".
(Esta ilustración se puede ver por separado )
La última reunión en este banco fue con el equipo de software de inversión. Fue con ella que resultó que escribir diagramas con un marcador en una hoja de papel es mejor que en una pizarra, e incluso mejor que en una pizarra inteligente.
Las fotos que ves son cómo se veía la sala de conferencias del hotel el cuarto día de nuestra reunión. Y utilizamos estos esquemas para buscar patrones, es decir, arquetipos.
Entonces les hago preguntas a los trabajadores, ellos anotan las respuestas con rotuladores de tres colores (negro, rojo y azul). Analizo sus respuestas en busca de arquetipos. Ahora analicemos todos los arquetipos en orden.
1.Hacer visible todo el trabajo: hacer visible el trabajo
La mayoría de empresas con las que trabajo tienen un porcentaje muy alto de trabajo desconocido. Por ejemplo, esto es cuando un empleado se acerca a otro y simplemente le pide que haga algo. En las organizaciones grandes, puede haber un 60% de trabajo no planificado. Y hasta el 40% del trabajo no está documentado de ninguna manera. Si fuera Boeing, no volvería a abordar su avión en mi vida. Si sólo se documenta la mitad del trabajo, entonces no se sabe si se está realizando correctamente o no. Todos los demás métodos resultan inútiles: no tiene sentido intentar automatizar nada, porque el 50% conocido puede ser la parte más coherente y clara del trabajo, cuya automatización no dará grandes resultados, y todo lo peor. las cosas están en la mitad invisible. En ausencia de documentación, es imposible encontrar todo tipo de trucos y trabajos ocultos, no encontrar cuellos de botella, esos mismos "Brents" de los que ya hablé. Hay un libro maravilloso de Dominica DeGrandis. . ella revela cinco "fugas de tiempo" diferentes (ladrones de tiempo):
- Demasiado trabajo en proceso (WIP)
- Dependencias desconocidas
- Trabajo no planificado
- Prioridades en conflicto
- Trabajo olvidado
Este es un análisis muy valioso y el libro es genial, pero todos estos consejos son inútiles si sólo el 50% de los datos son visibles. Los métodos propuestos por Dominica pueden utilizarse si se logra una precisión superior al 90%. Me refiero a situaciones en las que un jefe le asigna a un subordinado una tarea de 15 minutos, pero le lleva tres días; pero el jefe no sabe realmente que este subordinado depende de otras cuatro o cinco personas.
El Proyecto Phoenix es una historia maravillosa sobre un proyecto que llegó con tres años de retraso. Uno de los personajes se enfrenta al despido por esto y se encuentra con otro personaje que se presenta como una especie de Sócrates. Él ayuda a descubrir qué salió mal exactamente. Resulta que la empresa tiene un administrador de sistemas, cuyo nombre es Brent, y de alguna manera todo el trabajo pasa por él. En una de las reuniones, a uno de los subordinados le preguntan: ¿por qué cada tarea de media hora lleva una semana? La respuesta es una presentación muy simplificada de la teoría de las colas y la ley de Little, y en esta presentación resulta que con una ocupación del 90%, cada hora de trabajo toma 9 horas. Cada tarea debe enviarse a otras siete personas, de modo que la hora se convierta en 63 horas, 7 por 9. Lo que estoy diciendo es que para utilizar la Ley de Little o cualquier teoría de colas compleja, al menos necesitas tener datos.
Entonces cuando hablo de visibilidad no me refiero a que todo esté en la pantalla, sino a que al menos tengas datos. Cuando lo hacen, a menudo resulta que hay una gran cantidad de trabajo no planificado que de alguna manera se envía a Brent cuando no es necesario. Y Brent es un gran tipo, nunca dirá que no, pero tampoco le cuenta a nadie cómo hace su trabajo.
Cuando el trabajo es visible, los datos se pueden clasificar claramente (eso es lo que Dominique está haciendo en la foto), se puede aplicar la abstracción de las cinco fugas de tiempo y se puede aplicar la automatización.
2. Consolidar los sistemas de gestión del trabajo: gestión de tareas
Los arquetipos de los que hablo son una especie de pirámide. Si el primero se hace correctamente, el segundo ya es una especie de complemento. Muchos de estos no funcionan para nuevas empresas; es necesario tenerlos en cuenta para empresas más grandes como Fortune 5000. La última empresa para la que trabajé tenía 10 sistemas de emisión de billetes. Un equipo tenía Remedy, otro escribió algún tipo de su propio sistema, un tercero usó Jira y algunos se conformaron con el correo electrónico. El mismo problema surge si la empresa tiene 30 oleoductos diferentes, pero no tengo tiempo para discutir todos esos casos.
Hablo con la gente exactamente cómo se crean los tickets, qué les sucede a continuación y cómo se eluden. Lo más interesante es que en nuestras reuniones la gente habla con bastante sinceridad. Pregunté cuántas personas pusieron "impacto menor o nulo" en entradas a las que en realidad se les debería dar un "impacto mayor". Resultó que casi todo el mundo hace esto. No hago denuncias y trato de todas las formas posibles de no identificar a las personas. Cuando me confiesan algo sinceramente, no delato a la persona. Pero cuando casi todo el mundo pasa por alto el sistema, significa que toda la seguridad es esencialmente una fachada. Por lo tanto, no se pueden sacar conclusiones de los datos de este sistema.
Para resolver el problema del ticket, debes elegir un sistema principal. Si usas Jira, mantenlo Jira. Si hay alguna alternativa, que sea la única. La conclusión es que los tickets deben verse como un paso más en el proceso de desarrollo. Cada acción debe tener un ticket, que debe fluir a través del flujo de trabajo de desarrollo. Los tickets se envían al equipo, que los publica en el guión gráfico y luego se responsabiliza de ellos.
Esto se aplica a todos los departamentos, incluidos los de infraestructura y operaciones. En este caso, es posible formarse al menos una idea plausible de la situación. Una vez que se establece este proceso, de repente resulta fácil identificar quién es el responsable de cada solicitud. Porque ahora recibimos no el 50%, sino el 98% de los nuevos servicios. Si este proceso central funciona, la precisión mejora en todo el sistema.
Tubería de servicios
Nuevamente, esto sólo se aplica a las grandes corporaciones. Si es una empresa nueva en un campo nuevo, arremánguese y trabaje con su Travis CI o CircleCI. Cuando se trata de empresas Fortune 5000, un ejemplo de ello ocurrió en el banco donde trabajaba. Google se acercó a ellos y les mostró diagramas de antiguos sistemas IBM. Los chicos de Google preguntaron confundidos: ¿dónde está el código fuente de esto? Pero no hay código fuente, ni siquiera una GUI. Esta es la realidad a la que tienen que enfrentarse las grandes organizaciones: registros bancarios de 40 años de antigüedad en una antigua computadora central. Uno de mis clientes usa contenedores de Kubernetes con patrones Circuit Breaker, además de Chaos Monkey, todo para la aplicación KeyBank. Pero estos contenedores finalmente se conectan a una aplicación COBOL.
Los chicos de Google estaban completamente seguros de que resolverían todos los problemas de mi cliente y luego empezaron a hacer preguntas: ¿qué es IBM datapipe? Se les dice: este es un conector. ¿A qué se conecta? Al sistema Sperry. ¿Y qué es eso? Etcétera. A primera vista parece: ¿qué tipo de DevOps puede haber? Pero, de hecho, es posible. Existen sistemas de entrega que le permiten entregar el flujo de trabajo a los equipos de entrega.
3. Teoría de las Restricciones: Teoría de las Restricciones
Pasemos al tercer arquetipo: el conocimiento institucional/"tribal". Como regla general, en cualquier organización hay varias personas que lo saben todo y lo gestionan todo. Estos son los que llevan más tiempo en la organización y conocen todas las soluciones.
Cuando esto aparece en el diagrama, marco específicamente a esas personas con un marcador: por ejemplo, resulta que un tal Lou está presente en todas las reuniones. Y lo tengo claro: este es el Brent local. Cuando el CIO elige entre yo con camiseta y zapatillas deportivas y el tipo de IBM con traje, me eligen porque puedo decirle al director cosas que el otro no me dirá y que al director tal vez no le guste escuchar. . Les digo que el cuello de botella en su empresa es alguien llamado Fred y alguien llamado Lou. Es necesario desatar este cuello de botella, es necesario obtener de ellos sus conocimientos de una forma u otra.
Para resolver este tipo de problemas, puedo, por ejemplo, sugerir el uso de Slack. Un director inteligente preguntará: ¿por qué? Normalmente, en tales casos, los consultores de DevOps responden: porque todo el mundo lo hace. Si el director es realmente inteligente, dirá: ¿y qué? Y aquí es donde termina el diálogo. Y mi respuesta a esto es: porque hay cuatro cuellos de botella en la empresa: Fred, Lou, Susie y Jane. Para institucionalizar su conocimiento, primero hay que introducir Slack. Todos tus wikis son una completa tontería porque nadie sabe de su existencia. Si el equipo de ingeniería está involucrado en el desarrollo front-end y back-end y todos necesitan saberlo, pueden comunicarse con el equipo de desarrollo front-end o el equipo de infraestructura si tienen preguntas. Entonces es cuando Lou o Fred probablemente tendrán tiempo de unirse a la wiki. Y luego, en Slack, alguien podría preguntar por qué, digamos, el paso 5 no funciona y luego Lou o Fred corregirán las instrucciones en la wiki. Si estableces este proceso, muchas cosas se arreglarán por sí solas.
Este es mi punto principal: para recomendar cualquier alta tecnología, primero hay que poner en orden las bases para ella, y esto se puede hacer con las soluciones de baja tecnología que acabamos de describir. Si comienza con altas tecnologías y no explica por qué son necesarias, entonces, por regla general, esto no termina bien. Uno de nuestros clientes utiliza Azure ML, una solución muy económica y sencilla. Aproximadamente el 30% de sus preguntas fueron respondidas por la propia máquina de autoaprendizaje. Y esto fue escrito por operadores que no estaban involucrados en ciencia de datos, estadística o matemáticas. Esto es significativo. El costo de tal solución es mínimo.
4. Trucos de colaboración: trucos de colaboración
El cuarto arquetipo es la necesidad de combatir el aislamiento. La mayoría de la gente ya lo sabe: el aislamiento genera hostilidad. Si cada departamento está en su propio piso y las personas no se cruzan entre sí de ninguna manera, excepto en el ascensor, entonces la hostilidad entre ellos surge muy fácilmente. Pero si, por el contrario, las personas están juntas en la misma habitación, ella se marcha inmediatamente. Cuando alguien lanza alguna acusación general, por ejemplo, tal o cual interfaz nunca funciona, no hay nada más fácil para deconstruir tal acusación. Los programadores que escribieron la interfaz solo necesitan comenzar a hacer preguntas específicas y pronto quedará claro que, por ejemplo, el usuario simplemente estaba usando la herramienta incorrectamente.
Hay muchas maneras de superar el aislamiento. Una vez me pidieron que fuera consultor para un banco en Australia, pero me negué a hacerlo porque tengo dos hijos y una esposa. Todo lo que pude hacer para ayudarlos fue recomendarles narraciones gráficas. Esto es algo que está demostrado que funciona. Otra forma interesante son las reuniones de café magro. En una organización grande, esta es una excelente opción para difundir conocimientos. Además, puede realizar devopsdays internos, hackathons, etc.
5. Entrenando Kata
Como advertí al principio, no hablaré de esto hoy. Si estás interesado puedes echarle un vistazo. .
También hay una buena charla sobre este tema de Mike Rother:
6. Orientada al mercado: organización orientada al mercado
Hay diferentes problemas aquí. Por ejemplo, personas "I", personas "T" y personas "E". Las personas “yo” son aquellas que hacen una sola cosa. Normalmente existen en organizaciones con departamentos aislados. "T" es cuando una persona es buena en una cosa pero también buena en otras. "E" o incluso "peine" es cuando una persona tiene muchas habilidades.
La ley de Conway funciona aquí (), que en la forma más simplificada se puede expresar de la siguiente manera: si tres equipos trabajan en el compilador, el resultado será un compilador de tres partes. Por lo tanto, si hay un alto nivel de aislamiento dentro de una organización, entonces incluso Kubernetes, disyuntores, extensibilidad de API y otras cosas sofisticadas en esta organización se organizarán de la misma manera que la propia organización. Estrictamente según Conway y para fastidiar a todos los jóvenes geeks.
La solución a este problema se ha descrito muchas veces. Existen, por ejemplo, los arquetipos organizacionales descritos por Fernando Fernández. Esa arquitectura problemática de la que acabo de hablar, con aislamiento, es una arquitectura orientada a funciones. El segundo tipo es el peor, la arquitectura matricial, un desastre de los otros dos. El tercero es el que se ve en la mayoría de startups, y las grandes empresas también están intentando igualar este tipo. Es una organización orientada al mercado. Aquí optimizamos para lograr la respuesta más rápida a las solicitudes de los clientes. A esto a veces se le llama organización plana.
Mucha gente describe esta estructura de diferentes maneras, a mí me gusta la redacción. construir/ejecutar equipos, en Amazon lo llaman dos equipos de pizza. En esta estructura, todas las personas del tipo “I” se agrupan en torno a un servicio, y poco a poco se van acercando al tipo “T”, y si se cuenta con la gestión adecuada, pueden incluso convertirse en “E”. El primer argumento en contra es que dicha estructura contiene elementos innecesarios. ¿Por qué necesita un probador en cada departamento si puede tener un departamento especial de probadores? A lo que respondo: los sobrecostes en este caso son el precio para que toda la organización pase a ser tipo “E” en el futuro. En esta estructura, el evaluador aprende gradualmente sobre redes, arquitectura, diseño, etc. Como resultado, cada participante de la organización es plenamente consciente de todo lo que sucede en la organización. Si quieres saber cómo funciona este esquema en la industria, lee .
7. Auditores de desplazamiento a la izquierda: auditar al principio del ciclo. Cumplimiento de las normas de seguridad en exposición.
Aquí es cuando tus acciones no pasan la prueba del olfato, por así decirlo. La gente que trabaja para ti no es tonta. Si, como en el ejemplo anterior, aplicaron un impacto mínimo o nulo en todas partes, esto duró tres años y nadie notó nada, entonces todos saben perfectamente que el sistema no funciona. U otro ejemplo: un consejo asesor de cambios, donde los informes deben presentarse cada miércoles, por ejemplo. Allí trabaja un grupo de personas (no muy bien remuneradas, por cierto) que, en teoría, deberían saber cómo funciona el sistema en su conjunto. Y en los últimos cinco años, probablemente haya notado que nuestros sistemas son increíblemente complejos. Y cinco o seis personas tienen que tomar una decisión sobre un cambio que no hicieron y del que no saben nada.
Por supuesto, este enfoque no funciona. Tengo que deshacerme de esas cosas porque esta gente no protege el sistema. La decisión la debe tomar el propio equipo, porque el equipo debe ser responsable de ello. De lo contrario, surge una situación paradójica cuando un gerente que nunca ha escrito código en su vida le dice al programador cuánto tiempo debería llevar escribir el código. Una empresa con la que trabajé tenía 7 tableros diferentes que revisaban cada cambio, incluido un tablero de arquitectura, un tablero de producto, etc. Incluso hubo un período de espera obligatorio, aunque un empleado me dijo que en diez años de trabajo nadie había rechazado nunca un cambio realizado por esta persona durante este período obligatorio.
Es necesario invitar a los auditores a unirse a nosotros y no deshacerse de ellos. Dígales que escribe contenedores binarios inmutables que, si pasan todas las pruebas, permanecen inmutables para siempre. Dígales que tiene una canalización como código y explíqueles lo que eso significa. Muéstreles el siguiente esquema: un binario inmutable de solo lectura en un contenedor que pasa todas las pruebas de vulnerabilidad; y luego no sólo nadie lo toca, sino que ni siquiera toca el sistema que crea el pipeline, ya que también se crea dinámicamente. Tengo clientes, Capital One, que utilizan Vault para crear algo parecido a una cadena de bloques. El auditor no necesita mostrar las "recetas" del Chef, basta con mostrar la cadena de bloques, de la cual queda claro qué pasó con el ticket de Jira en producción y quién es el responsable de ello.
según , creado en 2018 por Sonatype, hubo 2017 mil millones de solicitudes de descarga de OSS en 87.
Las pérdidas sufridas debido a las vulnerabilidades son prohibitivas. Además, las cifras que ve arriba no incluyen los costos de oportunidad. ¿Qué es DevSecOps en pocas palabras? Permítanme decir de inmediato que no me interesa hablar sobre el éxito de este nombre. El punto es que dado que DevOps ha tenido tanto éxito, deberíamos intentar agregar seguridad a ese proceso.
Un ejemplo de esta secuencia:
Esta no es una recomendación para productos específicos, aunque me gustan todos. Los cité como ejemplo para mostrar que DevOps, que inicialmente se basó en el paradigma organizacional de la industria, permite automatizar cada etapa del trabajo en un producto.
Y no hay ninguna razón por la que no podamos adoptar el mismo enfoque en materia de seguridad.
Total
Como conclusión, daré algunos consejos para DevSecOps. Debe incluir auditores en el proceso de creación de sus sistemas y dedicar tiempo a educarlos. Es necesario cooperar con los auditores. A continuación, es necesario librar una lucha absolutamente despiadada contra los falsos positivos. Incluso con la herramienta de escaneo de vulnerabilidades más cara, puedes terminar creando hábitos extremadamente malos entre tus desarrolladores si no sabes cuál es tu relación señal-ruido. Los desarrolladores se sentirán abrumados con los eventos y simplemente los eliminarán. Si escuchó sobre la historia de Equifax, eso es más o menos lo que sucedió allí, donde se ignoró el nivel de alerta más alto. Además, las vulnerabilidades deben explicarse de manera que quede claro cómo afectan al negocio. Por ejemplo, se podría decir que se trata de la misma vulnerabilidad que en la historia de Equifax. Las vulnerabilidades de seguridad deben tratarse de la misma manera que otros problemas de software, es decir, deben incluirse en el proceso general de DevOps. Debes trabajar con ellos a través de Jira, Kanban, etc. Los desarrolladores no deben pensar que alguien más hará esto; al contrario, todos deberían hacerlo. Finalmente, es necesario gastar energía en capacitar a las personas.
Enlaces de interés
Aquí hay algunas charlas de la conferencia DevOops que pueden resultarle útiles:
- Sergey Berdnikov, Artyom Kalichkin - Historia de éxito o “Dev+DevOps+Ops” (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps a escala: una tragedia griega en tres actos (, )
- Alejandro Titov, Kirill Tolkachev -
- Timoteo Lister
Echa un vistazo a DevOops 2020 Moscú - También hay muchas cosas interesantes.
Fuente: habr.com