Get best of the week

Siete arquetipos de transformación de DevOps

La pregunta "cómo implementar un devopae" no es el primer año, pero no hay tantos buenos materiales. A veces se convierte en una víctima de la publicidad de consultores no muy inteligentes que necesitan vender su tiempo, no importa cómo. A veces, estas son palabras turbias y extremadamente generales sobre cómo las naves de megacorporaciones aran las extensiones del universo. Surge la pregunta: ¿qué hay de nosotros? Estimado autor, ¿puedes formular claramente tus ideas con una lista?

Todo esto proviene del hecho de que no hay mucha práctica real acumulada y comprensión del resultado de las transformaciones de la cultura de la empresa. Los cambios en la cultura son cosas de larga duración, cuyos resultados no aparecerán en una semana ni en un mes. Necesitamos a alguien lo suficientemente antiguo como para ver cómo se crearon y colapsaron las empresas a lo largo de los años.



John Willis- Uno de los padres de DevOps. Detrás de John, decenas de años de trabajo con una gran cantidad de empresas. Recientemente, John comenzó a notar por sí mismo patrones específicos que tienen lugar al trabajar con cada uno de ellos. Usando estos arquetipos, John guía a las compañías en 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 por Dell y Docker. Actualmente es vicepresidente de DevOps y prácticas digitales en SJ Technologies.

El siguiente es el relato en nombre de John.

Mi nombre es John Willis y la forma más fácil de encontrarme en Twitter es @botchagalupe . Tengo el mismo alias en Gmail y GitHub. Y en este enlace puede encontrar videos de mis informes y presentaciones para ellos.

Tengo muchas reuniones con los CIO de varias grandes empresas. Muy a menudo se quejan de que no entienden qué es DevOps, y todos los que intentan explicárselos están hablando de otra cosa. Otra queja común es que DevOps no funciona, aunque parece que los directores están haciendo todo como se les explicó. Estamos hablando 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 son las tecnologías más avanzadas, sino las soluciones relativamente de baja tecnología las más adecuadas. Durante semanas, conversé con personas de diferentes departamentos. Lo que ves en la primera foto de la publicación es mi último proyecto, la habitación se veía así después de tres días de trabajo.

¿Qué es DevOps?


De hecho, si le preguntas a 10 personas diferentes, te darán 10 respuestas diferentes. Pero lo que es interesante: todas estas diez respuestas serán correctas. No hay una respuesta incorrecta aquí. Estudié DevOps con bastante profundidad, durante unos 10 años, fui el primer estadounidense en el primer DevOpsDay. No diré que soy más inteligente que todos los involucrados en DevOps, pero casi no hay nadie que haya dedicado tanto esfuerzo en esto. Creo que DevOps surge cuando el capital humano y la tecnología se combinan. A menudo nos olvidamos de la dimensión humana, aunque hablamos mucho sobre todo tipo de culturas.



Ahora tenemos muchos datos, cinco años de investigación académica, la verificación de teorías se ha establecido a escala industrial. Estos estudios nos dicen lo siguiente: si combina algunos patrones de comportamiento en una cultura organizacional, puede obtener una aceleración de 2000 veces. Esta aceleración corresponde a la misma mejora en la estabilidad. Esta es una medida cuantitativa de los beneficios que DevOps puede aportar a cualquier empresa. Hace un par de años hablé de DevOps con un CEO de Fortune 5000. Cuando me estaba preparando para la presentación, estaba muy nervioso porque necesitaba exponer mis muchos años de experiencia en 5 minutos.

Terminé dando la siguiente definición de DevOps: Este es un conjunto de prácticas y patrones que hacen posible convertir el capital humano en capital organizacional altamente productivo. Un ejemplo es cómo Toyota ha estado trabajando durante los últimos 50 o 60 años.



(En lo sucesivo, dichos esquemas se presentan no como material de referencia, sino como una ilustración. Su contenido será diferente para cada nueva empresa. Sin embargo, la imagen se puede ver y ampliar por separado mediante este enlace).

Una de las prácticas más exitosas es la corriente de valor cartografía. Se han escrito varios buenos libros sobre esto, la autora de los más exitosos es Karen Martin. Pero durante el año pasado, llegué a la conclusión de que incluso este enfoque es de alta tecnología. Ciertamente tiene muchas ventajas, lo usé mucho. Pero cuando el CEO le pregunta por qué su compañía no puede pasar a nuevas pistas, es demasiado pronto para hablar sobre el mapeo de flujo de valor. Hay muchas preguntas mucho más fundamentales que deben responderse primero.

Me parece que el error de muchos de mis colegas es que simplemente le dan a la compañía una guía de cinco puntos, y luego regresan seis meses después y miran lo que sucedió. Incluso un buen circuito como el mapeo de flujo de valor tiene, digamos, puntos ciegos. Después de cientos de entrevistas con directores de varias compañías, elaboré un cierto patrón que nos permite descomponer el problema en 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 tengo todas las paredes colgadas con patrones. Recientemente trabajé con un fondo mutuo, y terminé con 100-150 de estos esquemas.

La mala cultura come buenos enfoques de desayuno


La idea principal es esta: no Lean, Agile, SAFE y DevOps ayudarán si la cultura de la organización es mala. Es lo mismo que bucear a las profundidades sin equipo de buceo u operar sin rayos X. En otras palabras, parafraseando a Drucker y Deming: una mala cultura organizacional se tragará cualquier buen sistema y no se ahogará.

Para resolver este problema principal, debe seguir los siguientes pasos:

  1. Hacer visible todo el trabajo : hacer que todo el trabajo sea visible. No en el sentido de que debe mostrarse en cualquier pantalla, sino en el sentido de que debe ser observable.
  2. Consolidate Work Management Systems: . «» 9 10 . «Phoenix Project» - , , - . «» . c .
  3. Theory of Constraints Methodology: .
  4. Collaboration hacks: .
  5. Toyota Kata (Coaching Kata): Toyota Kata . , .
  6. Market Oriented Organization: .
  7. Shift-left auditors: .




Empiezo a trabajar con la organización de manera muy simple: voy a la empresa y hablo con los empleados. Como puede ver, no hay alta tecnología. Todo lo que se necesita es seguir escribiendo. Reúno varios equipos en una habitación y analizo lo que me dicen desde el punto de vista de mis 7 arquetipos. Y luego les doy el marcador y les pido que escriban en la pizarra escribiendo todo lo que hasta ahora han dicho en voz alta. Por lo general, en tales reuniones hay una persona que escribe todo y, en el mejor de los casos, puede grabar el 10% de la discusión. Con mi método, esta cifra puede elevarse a aproximadamente el 40%.



(Para una ilustración separada, vea el enlace )

Mi enfoque se basa en el trabajo de William Schneider, The Reengineering Alternative) El enfoque se basa en la idea de que cualquier organización puede descomponerse en cuatro cuadrados. Este esquema para mí 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 poca competencia. Esta es una opción extremadamente indeseable: cuando todos caminan por la línea, pero nadie sabe qué hacer.

Una opción ligeramente mejor con un alto nivel de control y competencia. Si dicha empresa tiene ganancias, entonces quizás no necesite DevOps. Es muy interesante trabajar con una empresa que tiene un alto nivel de control, baja competencia y cooperación, pero al mismo tiempo un alto nivel de cultura (cultivo). Esto significa que la empresa tiene muchas personas a las que les gusta trabajar allí, la rotación laboral es baja.



(Puede ver esta ilustración por separado del enlace )

Me parece que los métodos con recomendaciones codificadas finalmente interfieren con el logro de la verdad. En particular, el mapeo de flujo de valor tiene muchas reglas sobre cómo estructurar la información. En las primeras etapas del trabajo del que estoy hablando ahora, nadie necesita estas reglas. Si una persona con un marcador en sus manos describe la situación real de la empresa en el tablero, esta es la mejor manera de entender la situación. Dicha información no llega a los directores. En este momento, es estúpido cortar a una persona y decir que dibujó una flecha equivocada. En esta etapa, es mejor usar reglas simples, por ejemplo: se puede crear una abstracción multinivel simplemente usando marcadores multicolores.

Repito, no hay alta tecnología. Un marcador negro representa la realidad objetiva, cómo funciona todo. Las personas marcan con un marcador rojo lo que no les gusta exactamente en el estado actual de las cosas. Es importante que lo escriban, no yo. Cuando voy al Director de Tecnología de la Información después de la reunión, no propongo una lista de 10 cosas que deben arreglarse. Me esfuerzo por encontrar una conexión entre lo que dicen las personas en la empresa y los patrones existentes y probados. Finalmente, un marcador azul sugiere posibles soluciones al problema.



(Por separado, esta ilustración se puede ver en el enlace )

Un ejemplo de este enfoque ahora se muestra arriba. A principios de este año trabajé con un banco. Los trabajadores del departamento de seguridad estaban convencidos de que no deberían venir a verificar los requisitos y el diseño (revisiones de diseño y requisitos).



(Puede ver esta ilustración por separado desde el enlace )

Y luego hablamos con personas de otros departamentos y resultó que hace unos 8 años, los desarrolladores de software expulsaron a los trabajadores de seguridad porque disminuyeron la velocidad. Y luego se convirtió en una prohibición, que se dio por sentado. Aunque de hecho no hubo prohibición.

Nuestra reunión fue un movimiento extremadamente confuso: durante aproximadamente tres horas, cinco equipos diferentes no pudieron explicarme qué estaba pasando entre el código y la asamblea. Y esto, al parecer, es lo más simple. La mayoría de los consultores de DevOps asumen de antemano que todos ya lo saben.

Luego, la persona a cargo del gobierno de TI, que permaneció 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é piensa sobre la reunión, y nunca olvidaré su respuesta. Él dijo: "Solía ​​pensar que solo había dos formas de entregar software en nuestro banco, y ahora sé que hay cinco de ellos, y ni siquiera sospechaba de tres".



(Por separado, esta ilustración se puede ver en el enlace )

La última reunión en este banco fue con el equipo de software de inversión. Fue con ella que resultó que escribir circuitos de marcadores con un marcador en una hoja es mejor que escribir en una pizarra, e incluso mejor que escribir en una pizarra inteligente.



Las fotografías que ve son el aspecto de la sala de conferencias del hotel el cuarto día de nuestra reunión. Y usamos estos patrones para buscar patrones, es decir, arquetipos.

Entonces, hago preguntas a los empleados, escriben las respuestas con marcadores de tres colores (negro, rojo y azul). Analizo sus respuestas para los arquetipos. Ahora discutamos todos los arquetipos en orden.

1. Hacer visible todo el trabajo: hacer visible el trabajo.


La mayoría de las empresas con las que trabajo tienen un porcentaje muy alto de trabajos desconocidos. Por ejemplo, esto es cuando un empleado acude a otro y solo pide hacer algo. En organizaciones grandes, puede haber 60% de trabajo no planificado. Y hasta el 40% del trabajo no está documentado de ninguna manera. Si fuera un Boeing, en mi vida nunca habría abordado su avión nuevamente. Si solo se documenta la mitad del trabajo, entonces no se sabe si este trabajo se realizó correctamente o no. Todos los demás métodos resultan inútiles: no tiene sentido tratar de automatizar algo, porque el conocido 50% puede ser solo la parte más coherente y clara del trabajo, cuya automatización no dará grandes resultados, y lo más terrible, en la mitad invisible. En ausencia de documentación, es imposible encontrar todo tipo de hacks y trabajos ocultos, no encontrar cuellos de botella,esos mismos "Brents" de los que ya he hablado. Hay un hermoso libro de Dominica De Grandis (Dominica DeGrandis)"Hacer visible el trabajo" . Identifica cinco diferentes " ladrones del tiempo":

  • Demasiado trabajo en proceso (WIP)
  • Dependencias desconocidas
  • Trabajo no planificado
  • Prioridades en conflicto
  • Trabajo descuidado


Este es un análisis muy valioso, y el libro es maravilloso, pero todos estos consejos son inútiles si solo el 50% de los datos son visibles. Puede aplicar los métodos propuestos por Dominica si la precisión se alcanza por encima del 90%. Estoy hablando de situaciones en las que el jefe le da al subordinado una tarea de 15 minutos y le toma tres días; pero el jefe no sabe realmente que este subordinado depende de otras cuatro o cinco personas.



El Proyecto Phoenix es una gran historia sobre un proyecto que tiene tres años de retraso. Uno de los héroes se ve amenazado con el despido debido a 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 compañía tiene un administrador del sistema, cuyo nombre es Brent, y todo el trabajo de alguna manera pasa por él. En una de las reuniones, se pregunta a uno de los subordinados: ¿por qué cada tarea de media hora toma una semana? En respuesta, sigue una declaración muy simplificada de la teoría de colas y la ley de Little, y en esta declaración resulta que con un 90% de empleo cada hora de trabajo lleva 9 horas. Cada tarea debe enviarse a otras siete personas, por lo que esta hora se convierte en 63 horas, 7 veces 9. Digo esto,Para usar la ley de Little o cualquier teoría de colas complicada, necesita al menos tener datos.

Por lo tanto, cuando hablo de visibilidad, no quiero decir que todo estaba en la pantalla, sino que es necesario al menos tener datos. Cuando lo son, a menudo resulta que hay una gran cantidad de trabajo no planificado, que por alguna razón se envía a Brent, aunque esto no es necesario. Y Brent es un gran tipo, nunca dirá que no, pero no le dice a nadie cómo hace su trabajo.



Cuando el trabajo es visible, puede clasificar con precisión los datos (eso es lo que hace Dominika en la foto), puede aplicar la abstracción de cinco fugas de tiempo y automatizarla.

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 realiza correctamente, el segundo ya es una especie de complemento. Muchos de ellos no funcionan para startups, deben tenerse en cuenta en el caso de grandes empresas, como las que están en la lista Fortune 5000. La última compañía donde trabajé tenía 10 sistemas de tickets. Remedy estaba en un equipo, otro escribió algún tipo de sistema propio, un tercero usó a Jira y alguien más se las arregló con el correo electrónico. El mismo problema surge si la compañía tiene 30 tuberías diferentes, pero no tengo tiempo para discutir todos estos casos.

Discuto con las personas exactamente cómo se crean los boletos, qué les sucede a continuación, cómo se eluden. Lo más interesante es que las personas en nuestras reuniones hablan con sinceridad. Pregunté cuántas personas configuraron "impacto menor / sin impacto" para las entradas a las que realmente se les debería haber asignado "impacto mayor". Resultó que casi todos lo hacen. No participo en denuncias y en todos los sentidos trato de no identificar a las personas. Cuando sinceramente me admiten en algo, no traiciono a una persona. Pero cuando casi todos pasan por alto el sistema, esto significa que toda la seguridad, en esencia, es una decoración. Por lo tanto, no se pueden sacar conclusiones de los datos de este sistema.

Para resolver el problema con los tickets, debe seleccionar un sistema principal. Si usa Jira, que sea solo Jira. Si hay alguna alternativa, que sea solo eso. La conclusión es que los tickets deben considerarse como otro paso en el proceso de desarrollo. Cualquier acción debe tener un ticket que debe pasar por el flujo de trabajo de desarrollo. Los boletos se envían al equipo, que los coloca en el guión gráfico y luego es responsable de ellos.

Esto se aplica a todos los departamentos, incluidas la infraestructura y las operaciones. En este caso, puede inventar al menos una idea plausible del estado de cosas. Cuando se establece este proceso, de repente resulta que puede establecer fácilmente quién es responsable de cada aplicación. Porque ahora no recibimos el 50%, sino el 98% de los nuevos servicios. Si este proceso básico funciona, la precisión mejora en todo el sistema.

Servicios de ductos


De nuevo, esto solo se aplica a las grandes corporaciones. Si es una nueva empresa en un nuevo campo, arremangue y trabaje con su Travis CI o CircleCI. En cuanto a las compañías Fortune 5000, el caso que sucedió con el banco donde trabajé fue indicativo. Vinieron a ellos desde Google, y se les mostraron diagramas con viejos sistemas IBM. Los chicos de Google con un malentendido preguntaron: ¿dónde está el código fuente para esto? Y no hay código fuente, ni siquiera una GUI. Esta es la realidad con la que las grandes organizaciones tienen que trabajar: registros bancarios de 40 años en un mainframe antiguo. Uno de mis clientes usa contenedores Kubernetes con patrones de Circuit Breaker, además de Chaos Monkey, todo para KeyBank. Pero estos contenedores eventualmente se conectan a la aplicación COBOL.

Los chicos de Google confiaron plenamente en que resolverían todos los problemas de mi cliente, y luego comenzaron a hacer preguntas: ¿qué es el datapipe de IBM? Se les responde: este es un conector. ¿A qué se conecta? Al sistema Sperry. ¿Y qué es eso? Etc. A primera vista parece: ¿qué tipo de DevOps puede ser? Pero, de hecho, es posible. Existen sistemas de entrega que le permiten transferir el flujo de trabajo a los equipos de entrega.

3. Teoría de las restricciones: teoría de las restricciones


Pasemos al tercer arquetipo: conocimiento institucional / "tribal". Como regla general, en cualquier organización hay varias personas que lo saben todo y lo manejan todo. Estos son aquellos que trabajan más tiempo en la organización y que conocen todas las soluciones.



Cuando esto se revela en el diagrama, dibujo especialmente un marcador alrededor de esas personas: por ejemplo, resulta que cierto Lou está presente en todas las reuniones. Y para mí está claro: este es el Brent local. Cuando el CIO elige entre mí con una camiseta y zapatillas de deporte y un chico vestido con un traje de IBM, soy elegido porque puedo decirle al director sobre cosas que el otro chico no contará y sobre las cuales el director tal vez no quiera escuchar. Les digo que hay un cuello de botella en su compañía, es alguien llamado Fred y alguien llamado Lu. Este cuello de botella debe desatarse, su conocimiento debe obtenerse de una forma u otra de ellos.

Para resolver este tipo de problema, puedo, por ejemplo, sugerir usar Slack. Un director inteligente pregunta por qué. Por lo general, en tales casos, los consultores de DevOps responden: porque todos lo hacen. Si el director es realmente inteligente, dirá: ¿y qué? Y aquí es donde termina el diálogo. Y respondo esto: porque la compañía tiene cuatro cuellos de botella, Fred, Lou, Susie y Jane. Para institucionalizar su conocimiento, primero debe presentar Slack. Todos tus wikis son completamente absurdos porque nadie sabe acerca de su existencia. Si el equipo de ingenieros se dedica al desarrollo externo e interno y todos deben saber que puede ponerse en contacto con el equipo de desarrollo externo o el equipo de infraestructura con preguntas. En ese momento, probablemente Lou o Fred tendrán tiempo para conectarse a la wiki. Y luego en Slack, alguien podría preguntarpor qué no funciona, por ejemplo, paso 5. Y luego Lou o Fred corregirán las instrucciones en la wiki. Si establece este proceso, muchas cosas encajarán.

Esta es mi idea principal: para recomendar algunas tecnologías avanzadas, primero debe poner en orden las bases para ellas, y puede hacerlo con las soluciones de baja tecnología recién descritas. Si comienza con alta tecnología y no explica por qué son necesarios, entonces, como regla, esto no termina con nada bueno. Uno de nuestros clientes usa Azure ML, una solución muy barata y fácil. En algún lugar, el 30% de las preguntas fueron respondidas por la máquina de autoaprendizaje. Y los operadores que no se ocuparon de la ciencia de datos, las estadísticas o las matemáticas escribieron esto. Esto es indicativo. 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 luchar contra el aislamiento. La mayoría de la gente ya sabe sobre esto: el aislamiento genera enemistad. 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. Y si, por el contrario, las personas están en la misma habitación, ella se va inmediatamente. Cuando alguien lanza algún tipo de acusación general, por ejemplo, tal y tal interfaz nunca funciona, no hay nada más fácil de deconstruir tal acusación. Es suficiente que los programadores que escribieron la interfaz comiencen a hacer preguntas específicas, y pronto queda claro que, por ejemplo, el usuario simplemente usó la herramienta incorrectamente.

Hay muchas formas de superar el aislamiento. Una vez me pidieron que asesorara a un banco en Australia, me negué a hacerlo porque tengo dos hijos y una esposa. Todo lo que pude ayudarles fue recomendarles narraciones gráficas. Esto es algo que probablemente funciona. Otra forma interesante son las reuniones en formato de café magro. En una organización grande, esta es una excelente manera de difundir el conocimiento. Además, puede tener devopsdays internos, hackathons, etc.

5. Entrenando Kata


Como ya advertí al principio, hoy no hablaré sobre eso. Si está interesado, puede ver algunas de mis presentaciones .

También hay un buen informe sobre este tema de Mike Rother:



6. Orientado al mercado: una organización orientada al mercado


Hay varios problemas aquí. Por ejemplo, personas "I", personas "T" y personas "E". Las personas "yo" son aquellas que se dedican a una sola cosa. Por lo general, existen en organizaciones con unidades aisladas. "T" es si una persona sabe bien una cosa, pero también sobresale en otras. Una "E" o incluso un "peine" es cuando una persona tiene muchas habilidades. La ley de Conway



funciona aquí , que en la forma más simplificada puede establecerse de la siguiente manera: si los tres equipos están involucrados en el compilador, el resultado será un compilador de tres partes. Por lo tanto, si la organización tiene un alto nivel de aislamiento, incluso Kubernetes, disyuntor, extensibilidad API y otras cosas de moda en esta organización se organizarán de la misma manera que la organización misma. Estrictamente de acuerdo con Conway y, a pesar de todos ustedes, jóvenes geeks.

La solución a este problema se ha descrito muchas veces. Hay, por ejemplo, arquetipos organizacionales descritos por Fernando Fernández. La 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 de matriz, hay un desastre de los otros dos. El tercero es lo que se ve en la mayoría de las nuevas empresas, y las grandes empresas también están tratando de igualar este tipo. Es una organización orientada al mercado. Aquí está la optimización para lograr la respuesta más rápida a las solicitudes de los clientes. Esto a veces se llama organización plana.

Muchas personas describen esta estructura de diferentes maneras, me gusta la redacción de los equipos de construcción / ejecución , en Amazon lo llaman dos equipos de pizza. En esta estructura, todas las personas del tipo "I" se agrupan alrededor de un servicio, y gradualmente se acercan al tipo "T", y si se establece la gestión correcta, incluso se puede convertir en "E". El primer contraargumento aquí es que hay elementos superfluos en dicha estructura. ¿Por qué necesitamos un probador en cada departamento, si puede tener un departamento especial de probadores? A lo que respondo: el exceso de costos en este caso es el precio para asegurar que en el futuro toda la organización se convierta en tipo "E". En esta estructura, el probador aprende gradualmente sobre redes, arquitectura, diseño, etc. Como resultado, cada miembro de la organización es plenamente consciente de todo lo que sucede en la organización. Si quieres saber cómo funciona este circuito en la industria, echa un vistazo a Mike Rother, Toyota Kata .

7. Auditores con desplazamiento a la izquierda: auditan en las primeras etapas de un ciclo. Cumplimiento de las normas de seguridad.


Esto es cuando sus acciones no pasan, por así decirlo, una prueba de olor. Las personas que trabajan para ti no son estúpidas. Si, como en el ejemplo anterior, en todas partes exhibieron un impacto menor / nulo, esto duró tres años, y nadie notó nada, entonces todos saben que el sistema no está funcionando. Otro ejemplo es la junta asesora de cambio, donde cada, digamos, el entorno necesita ser reportado. Allí trabaja un grupo de personas (por cierto, no muy bien remunerado), 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 deben decidir sobre un cambio que no hicieron y sobre el que no saben nada.

Por supuesto, este enfoque no funciona. Tengo que deshacerme de esas cosas, porque estas personas no protegen el sistema. La decisión debe ser tomada por el propio equipo, porque el equipo debe ser responsable de ello. De lo contrario, surge una situación paradójica cuando el gerente, que nunca ha escrito código en su vida, le dice al programador cuánto tiempo lleva escribir el código. En una empresa con la que trabajé, había 7 consejos diferentes que analizaban cada cambio, incluida una arquitectura, un producto, etc. Incluso hubo un período de espera obligatorio, aunque un empleado me dijo que en diez años de trabajo, nadie en este período obligatorio había rechazado los cambios realizados por esta persona.

Los auditores deben llamarse a sí mismos y no deshacerse de ellos. Dígales que está escribiendo contenedores binarios inmutables que, si pasan todas las pruebas, permanecerán sin cambios para siempre. Dígales que tiene una tubería como código y explique lo que eso significa. Muéstreles el siguiente diagrama: binario inmutable de solo lectura en un contenedor que pasa todas las pruebas de vulnerabilidad; y luego, no solo nadie lo toca, ni siquiera toca el sistema que crea la tubería, porque también se crea dinámicamente. Tengo clientes, Capital One, que usan Vault para crear algo así como una cadena de bloques. No puede mostrar las "recetas" del Chef al auditor, solo muestre la cadena de bloques, de la que queda claro qué sucedió con el boleto de Jira en producción y quién es responsable de ello.



De acuerdo con el informecreado por Sonatype en 2018, hubo 87 mil millones de solicitudes de descarga de OSS en 2017.



Las vulnerabilidades incurridas son prohibitivas. Además, las cifras que ve arriba no incluyen los costos de oportunidad. En pocas palabras sobre qué es DevSecOps. Quiero decir de inmediato que no estoy interesado en hablar sobre el éxito de este nombre. El punto es que, dado que DevOps tuvo mucho éxito, debe intentar agregar seguridad a esta tubería.

Un ejemplo de tal secuencia:


esta no es una recomendación para ciertos productos, aunque me gustan todos. Los cité como un ejemplo para mostrar que DevOps, basado inicialmente en el paradigma de la organización en la industria, le permite automatizar cada etapa del trabajo en un producto.



Y no hay ninguna razón por la que no podamos adoptar el mismo enfoque de seguridad.

Total


Como conclusión, daré algunos consejos para DevSecOps. Debe incluir auditores en el proceso de creación de sus sistemas, dedicar tiempo a su educación. Es necesario cooperar con los auditores. Además, es necesario librar una lucha absolutamente despiadada contra los falsos positivos. Incluso con la herramienta de escaneo de vulnerabilidades más costosa, puede terminar creando hábitos extremadamente malos para sus desarrolladores si no sabe qué es la relación señal / ruido. Los desarrolladores estarán sobrecargados con eventos, y simplemente los eliminarán. Si escuchó sobre la historia con Equifax, entonces eso es lo que sucedió allí, la señal del nivel de peligro más alto fue ignorada allí. Además, las vulnerabilidades deben explicarse para que quede claro cómo afectan al negocio. Por ejemplo, podemos decir que esta es la misma vulnerabilidad que en la historia de Equifax. Vulnerabilidades de seguridadDebe considerar lo mismo que otros problemas con el software, es decir, deben incluirse en el proceso general de DevOps. Necesitas trabajar con ellos a través de Jira, Kanban, etc. Los desarrolladores no deberían pensar que alguien más lo hará; por el contrario, todos deberían hacerlo. Finalmente, debe gastar energía en educar a las personas.

Enlaces útiles


Aquí hay algunas charlas de la conferencia DevOops que pueden serle útiles:



Eche un vistazo al programa DevOops 2020 Moscú : también hay muchas cosas interesantes allí.

More articles:


All Articles