La pregunta de «cómo implementar DevOps en nuestra empresa» lleva años en la mente de muchos, pero hay pocos materiales de calidad al respecto. A veces, te conviertes en víctima de publicidad de consultores poco inteligentes, que solo desean vender su tiempo, sin importar cómo. En otras ocasiones, se oyen palabras vagas y generales sobre cómo las naves de megacorporaciones surcan los vastos dominios del universo. Surge la pregunta: ¿y a nosotros, qué? Estimado autor, ¿podrías formular claramente tus ideas en una lista?
Todo esto se debe a que no hay mucha práctica real y comprensión de los resultados de las transformaciones culturales en las empresas. Los cambios culturales son procesos prolongados, cuyos resultados no se verán ni en una semana ni en un mes. Necesitamos a alguien con suficiente experiencia, que haya visto cómo se crean y colapsan las empresas a lo largo de los años.
John Willis es uno de los padres de DevOps. John cuenta con décadas de experiencia trabajando con un gran número de empresas. Recientemente, ha comenzado a notar patrones específicos que se presentan en el trabajo con cada una de ellas. Utilizando estos arquetipos, John guía a las empresas en el verdadero camino de la transformación DevOps. Más sobre estos arquetipos se puede encontrar en la traducción de su presentación en la conferencia DevOops 2018.
Acerca del ponente:
Con más de 35 años en gestión de TI, participó en la creación del precursor de OpenCloud en Canonical, estuvo involucrado 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.
A continuación, la narración en voz de John.
Me llamo John Willis, y es más fácil encontrarme en Twitter, . Ese mismo seudónimo tengo en Gmail y GitHub. Y donde podrás encontrar grabaciones de mis charlas y presentaciones.
Tengo muchas reuniones con CIO de diferentes grandes empresas. Frecuentemente se quejan de que no entienden qué es DevOps, y todos los que intentan explicárselo hablan de algo diferente. Otra queja común es que DevOps no funciona, aunque los directores parecen seguir las instrucciones dadas. Se trata 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, las soluciones de baja tecnología son más adecuadas que las de alta tecnología. Pasé semanas conversando con personas de diferentes departamentos. Lo que ves en la primera imagen de la publicación es cómo se veía la sala después de tres días de trabajo en mi último proyecto.
¿Qué es DevOps?
De hecho, si le preguntas a 10 personas diferentes, darán 10 respuestas distintas. Pero aquí está lo interesante: todas esas diez respuestas serán correctas. No hay una respuesta incorrecta. He estado involucrado en DevOps durante aproximadamente 10 años, fui el primer estadounidense en el primer DevOpsDay. No diré que soy más inteligente que todos los que trabajan en DevOps, pero dudo que haya alguien que haya invertido tanto esfuerzo como yo. Creo que DevOps surge cuando el capital humano se une a la tecnología. A menudo olvidamos la dimensión humana, aunque hablamos mucho de todo tipo de culturas.
Ahora tenemos muchos datos, cinco años de investigaciones académicas, la validación de teorías está establecida a escala industrial. Estas investigaciones nos dicen lo siguiente: si en la cultura organizacional se combinan ciertos patrones de comportamiento, se puede obtener una aceleración de hasta 2000 veces. Esta aceleración corresponde a la misma mejora en la resiliencia. Esta es una medición cuantitativa de la ventaja que DevOps puede ofrecer a cualquier empresa. Hace un par de años, hablé sobre DevOps con el CEO de una empresa de la lista Fortune 5000. Cuando me estaba preparando para la presentación, estaba muy nervioso porque necesitaba resumir mis años de experiencia en 5 minutos.
Al final, di la siguiente definición de DevOps: es un conjunto de prácticas y patrones que permiten transformar el capital humano en un capital organizacional de alto rendimiento. Un ejemplo es cómo Toyota ha operado durante los últimos 50 o 60 años.
(A partir de aquí, estos esquemas no se presentan como material de referencia, sino como ilustración. Su contenido variará para cada nueva empresa. Sin embargo, se puede observar la imagen por separado y aumentarla.
Una de las prácticas más exitosas es mapeo de la cadena de valor. Se han escrito varios buenos libros sobre esto, el autor de los más exitosos es Karen Martin. Sin embargo, en el último año he llegado a la conclusión de que incluso este enfoque es demasiado tecnológico. Sin duda, tiene muchas ventajas, de las cuales he hecho uso. Pero cuando el director general te pregunta por qué su empresa no puede cambiar a nuevos rieles, todavía es muy prematuro hablar de mapeo de la cadena de valor. Hay muchas preguntas mucho más fundamentales que necesitan respuestas previas.
Me parece que el error de muchos de mis colegas es que simplemente le dan a la empresa una guía de cinco puntos y luego regresan después de seis meses para ver qué ha pasado. Incluso un buen esquema como el mapeo de la cadena de valor tiene, digamos, zonas muertas (blind spots). Después de cientos de entrevistas con directores de diversas empresas, he desarrollado un cierto patrón que permite descomponer el problema en partes componentes, y ahora discutiremos cada una de estas partes. Antes de aplicar cualquier solución tecnológica, utilizo este patrón, y como resultado, todas mis paredes terminan llenas de esquemas. Recientemente trabajé con un fondo mutuo, y al final tenía entre 100 y 150 de estos esquemas.
Una mala cultura se come buenos enfoques en el desayuno.
La idea principal es la siguiente: ninguna de las metodologías Lean, Agile, SAFE y DevOps ayudará si la cultura de la organización es mala. Es como bucear en profundidad sin tanque de oxígeno o operar sin radiografía. En otras palabras, parafraseando a Drucker y Deming: una mala cultura organizativa absorbe cualquier buen sistema y no se atraganta.
Para resolver este problema principal, es necesario llevar a cabo los siguientes pasos:
- Hacer Todo el Trabajo Visible: es necesario hacer todo el trabajo visible. No en el sentido de que deba mostrarse en alguna pantalla, sino en el sentido de que debe ser observable.
- Consolidar los Sistemas 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 estaba en una sola persona, Brent, cuya causa hizo que el proyecto se retrasara tres años. Y encuentro a esos "Brents" por todas partes. Para resolver estos cuellos de botella utilizo los siguientes dos puntos de nuestra lista.
- Metodología de Teoría de Restricciones: teoría de restricciones.
- Trucos de colaboración: hackeos de colaboración.
- Toyota Kata (): no hablaré mucho sobre Toyota Kata. Si te interesa, en mi GitHub casi sobre cada uno de estos temas.
- Organización Orientada al Mercado: organización orientada al mercado.
- Auditores Shift-left: auditoría en etapas tempranas del ciclo.
Empiezo a trabajar con la organización de una manera muy simple: voy a la empresa y hablo con los empleados. Como se puede ver, no hay alta tecnología. Todo lo que se necesita es tener algo para escribir. Reúno a varios equipos en una habitación y analizo lo que me dicen, desde la perspectiva de mis 7 arquetipos. Luego les doy un marcador y les pido que escriban en la pizarra todo lo que hasta ahora han dicho en voz alta. Normalmente, en este tipo de reuniones hay una persona que toma notas, y en el mejor de los casos consigue registrar el 10% de la discusión. Con mi método, este porcentaje se logra aumentar a alrededor del 40%.
(Esta ilustración se puede )
Mi enfoque se basa en el trabajo de William Schneider (William Schneider, ). En la base del enfoque está la idea de que cualquier organización se puede descomponer en cuatro cuadrantes. Este esquema generalmente es el resultado del trabajo con las cientos de otras esquemas que surgen al analizar una organización. Supongamos que tenemos una organización con un alto nivel de control, pero con una baja competencia. Esta es una opción extremadamente indeseable: cuando todos siguen órdenes, pero nadie sabe qué hacer.
Una opción un poco mejor con un alto nivel de control y competencia. Si una empresa es rentable, tal vez no necesite DevOps. Es más interesante trabajar con una empresa que tiene un alto nivel de control, baja competencia y colaboración, pero al mismo tiempo una alta cultura (cultivation). Esto significa que hay muchas personas en la empresa que disfrutan trabajar allí, y la rotación de personal es baja.
(Esta ilustración se puede )
Me parece que los métodos con recomendaciones estrictamente definidas, en última instancia, obstaculizan la búsqueda de la verdad. En particular, en el mapeo del flujo de valor hay muchas reglas sobre cómo estructurar la información. En las etapas iniciales de trabajo, de las que ahora hablo, estas reglas no son necesarias para nadie. Si una persona con un marcador en la mano describe en la pizarra la situación real en la empresa, esa es la mejor manera de entender la situación. Esa información no llega a los directores. En ese momento, es tonto interrumpir a la persona y decirle que ha dibujado mal alguna flecha. En esta etapa, es mejor seguir reglas simples; por ejemplo, se puede crear una abstracción multinivel simplemente utilizando marcadores de diferentes colores.
Reitero, sin alta tecnología. Con un marcador negro se representa la realidad objetiva, cómo funciona todo. Con un marcador rojo, las personas indican lo que no les gusta en la situación actual. Es importante que lo escriban ellos, no yo. Cuando después de la reunión voy a ver al director de tecnología de la información, no propongo una lista de 10 cosas que necesitan ser corregidas. Busco encontrar conexiones entre lo que dicen las personas de la empresa y los patrones probados existentes. Finalmente, con un marcador azul se proponen posibles soluciones al problema.
(Esta ilustración se puede )
Un ejemplo de este enfoque se muestra arriba. A principios de este año trabajé con un banco. Los empleados del departamento de seguridad estaban convencidos de que no podían asistir a las revisiones de requisitos y diseño (design and requirement reviews).
(Esta ilustración se puede )
Luego hablamos con personas de otros departamentos y descubrimos que hace aproximadamente 8 años los desarrolladores de software expulsaron a los trabajadores de seguridad porque estaban ralentizando el trabajo. Y luego eso se convirtió en una prohibición que se percibía como un hecho. Sin embargo, en realidad no había tal prohibición.
Nuestra reunión tuvo un desarrollo bastante confuso: durante alrededor de tres horas, cinco equipos diferentes no lograban explicarme qué estaba ocurriendo entre el código y la compilación. Y esto, aparentemente, es lo más sencillo. La mayoría de los consultores de DevOps suponen de antemano que esto ya es conocido por todos.
Luego, la persona encargada de la gobernanza de TI, que había permanecido en silencio durante cuatro horas, de repente cobró vida cuando llegamos a su tema y nos ocupó durante mucho tiempo. Al final, le pregunté qué pensaba de la reunión, y nunca olvidaré su respuesta. Dijo: 'Antes pensaba que en nuestro banco había solo dos formas de entrega de software, y ahora sé que hay cinco, y ni siquiera sospechaba de tres de ellas'.
(Esta ilustración se puede )
La última reunión en este banco fue con el equipo que desarrolla software para inversiones. Fue en esta ocasión que descubrimos que es mejor escribir esquemas con un marcador en un papel que en una pizarra, e incluso mejor que en una pizarra inteligente.
Las fotos que ven son cómo lució la sala de conferencias del hotel en el cuarto día de nuestra reunión. Y utilizamos estos esquemas para buscar patrones, es decir, arquetipos.
Así que hago preguntas a los empleados, y ellos registran las respuestas con marcadores de tres colores (negro, rojo y azul). Analizo sus respuestas en busca de arquetipos. Ahora, discutamos todos los arquetipos en orden.
1. Make All Work Visible: Hacer todo el trabajo visible
En la mayoría de las empresas con las que trabajo, hay un porcentaje muy alto de trabajo desconocido. Por ejemplo, es cuando un empleado se acerca a otro y simplemente le pide que haga algo. En grandes organizaciones, puede haber un 60% de trabajo no planificado. Y hasta un 40% del trabajo no está documentado de ninguna manera. Si fuera Boeing, realmente nunca más volvería a subir a uno de sus aviones. Si solo se documenta la mitad del trabajo, no se sabe si ese trabajo se está realizando correctamente o no. Todos los demás métodos resultan inútiles: no tiene sentido intentar automatizar algo porque el 50% conocido puede ser, de hecho, la parte más organizada y clara del trabajo, cuya automatización no dará grandes resultados, y todo lo que es terrible está en la mitad invisible. Sin documentación, es imposible encontrar todo tipo de trucos y trabajo oculto, no se pueden identificar los cuellos de botella, esos mismos 'Brentos' de los que ya he hablado. Hay un excelente libro de Dominica DeGrandis . Ella identifica cinco diferentes 'fugas de tiempo' (thieves of time):
- Demasiado trabajo en proceso (WIP)
- Dependencias desconocidas
- Trabajo no planificado
- Prioridades en conflicto
- Trabajo descuidado
Es un análisis muy valioso, y el libro es impresionante, pero todos estos consejos son inútiles si solo se ven el 50% de los datos. Se pueden aplicar los métodos propuestos por Dominica solo si se alcanza una precisión superior al 90%. Estoy hablando de situaciones en las que un jefe le da a un subordinado una tarea de 15 minutos, y esta ocupa tres días, pero el jefe en realidad no sabe que este subordinado depende de otras cuatro o cinco personas.
Phoenix Project es una maravillosa historia sobre un proyecto que se retrasó tres años. Uno de los personajes se enfrenta a un despido por esto, y se encuentra con otro personaje que se presenta como una especie de Sócrates. Este último ayuda a entender qué salió mal. Se descubre que en la empresa hay un administrador de sistemas llamado Brent, y todo el trabajo pasa, de una forma u otra, a través de él. En una de las reuniones, uno de los subordinados pregunta: ¿por qué cada tarea de media hora toma una semana? La respuesta es una exposición muy simplificada de la teoría de colas y la ley de Little, y en esta exposición se revela que con un 90% de ocupación, cada hora de trabajo ocupa 9 horas. Cada tarea debe ser enviada a siete personas más, por lo que esa hora se convierte en 63 horas, 7 multiplicado por 9. Digo esto porque, para utilizar la ley de Little o cualquier teoría de colas algo compleja, se necesita tener datos.
Por lo tanto, cuando hablo de visibilidad, no me refiero a que todo esté en la pantalla, sino a que al menos se cuente con datos. Cuando los hay, a menudo se revela que hay un gran volumen de trabajo no planificado que, por alguna razón, se envía a Brent, aunque no hay necesidad de ello. Y Brent es un gran tipo, nunca dirá 'no', pero al mismo tiempo no le cuenta a nadie cómo realiza su trabajo.
Cuando el trabajo es visible, se pueden clasificar los datos de manera ordenada (justo lo que Dominika está haciendo en la foto), se puede aplicar la abstracción de las cinco fugas de tiempo y automatizar.
2. Consolidar Sistemas de Gestión de 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 superestructura. Muchos de ellos no funcionan para startups, deben tenerse en cuenta en grandes empresas, como las que figuran en la lista Fortune 5000. En la última empresa donde trabajé, había 10 sistemas de seguimiento de errores (ticketing system). En un equipo teníamos Remedy, otro escribió su propio sistema, el tercero usaba Jira, y algunos se las arreglaban solo con correo electrónico. El mismo problema surge si hay 30 diferentes pipelines en una empresa, pero no tengo tiempo para discutir todos esos casos.
Discuto con las personas sobre cómo se crean los tickets, qué sucede con ellos después y cómo se evitan. Lo más interesante es que las personas en nuestras reuniones hablan con bastante sinceridad. Pregunté cuántas personas etiquetan como «menor / sin impacto» los tickets que en realidad deberían tener la etiqueta «gran impacto». Resultó que casi todos lo hacen. No me dedico a delatar y trato de no identificar a las personas. Cuando alguien me confiesa algo sinceramente, no revelo su identidad. Pero cuando prácticamente todos evitan el sistema, significa que toda la seguridad es, en esencia, una mera fachada. Por lo tanto, no se pueden sacar conclusiones de los datos de este sistema.
Para resolver el problema de los tickets, es necesario elegir un sistema principal. Si usas Jira, que sea solo Jira. Si hay alguna alternativa, que sea solo esa. La esencia es que los tickets deben considerarse como otra etapa del proceso de desarrollo. Cada acción debe tener un ticket que pase por el proceso de desarrollo. Los tickets se envían al equipo, que los coloca en el storyboard y luego es responsable de ellos.
Esto afecta a todos los departamentos, incluidos el de infraestructura y el operativo. En tal caso, se puede crear una representación más o menos creíble de la situación. Cuando este proceso está en marcha, de repente se puede establecer fácilmente quién es responsable de cada aplicación. Porque ahora obtenemos no el 50%, sino el 98% de los nuevos servicios. Si este proceso principal funciona, la precisión mejora en todo el sistema.
Pipeline de servicios
Esto se refiere nuevamente únicamente a grandes corporaciones. Si eres una nueva empresa en un nuevo campo, arremángate y trabaja con tu Travis CI o CircleCI. En cuanto a las empresas Fortune 5000, el caso que viví en el banco donde trabajaba es revelador. Vinieron de Google y les mostraron gráficos con viejos sistemas de IBM. Los chicos de Google preguntaron con incredulidad: ¿y dónde está el código fuente para esto? No hay código fuente, ni siquiera GUI. Esta es la realidad con la que tienen que lidiar las grandes organizaciones: registros bancarios de 40 años en un antiguo mainframe. Uno de mis clientes utiliza contenedores Kubernetes con patrones de Circuit Breaker, además de Chaos Monkey, todo para la aplicación KeyBank. Pero esos contenedores, al final, se conectan a una aplicación en COBOL.
Los chicos de Google estaban completamente seguros de que resolverían todos los problemas de mi cliente, y luego comenzaron a hacer preguntas: ¿qué es el IBM datapipe? Les responden: es un conector. ¿Con qué se conecta? Al sistema Sperry. ¿Y eso qué es? Y así sucesivamente. A primera vista parece: ¿dónde está el DevOps aquí? Pero en realidad, sí es posible. Existen sistemas de entrega que permiten pasar el flujo de trabajo a los equipos encargados de la entrega.
3. Teoría de las Restricciones: Teoría de las restricciones
Pasemos al tercer arquetipo: conocimiento institucional / "tribal". Generalmente, en cualquier organización hay varias personas que lo saben todo y dirigen a todos. Son aquellos que han estado más tiempo en la organización y conocen todos los atajos.
Cuando esto se identifica en el gráfico, específicamente marco a estas personas con un resaltador: por ejemplo, resulta que un tal Lou está presente en todas las reuniones. Y para mí está claro: es el Brent local. Cuando el director de TI elige entre mí en una camiseta y zapatillas y un tipo de IBM vestido de traje, me eligen a mí porque puedo contarle al director cosas que el otro chico no le dirá y que pueden resultarle incómodas. Les digo que en su empresa hay un cuello de botella, que es alguien llamado Fred y otra persona llamada Lou. Es necesario deshacer ese cuello de botella; hay que extraer su conocimiento de alguna manera.
Para abordar este tipo de problema, puedo, por ejemplo, proponer usar Slack. Un director ingenioso preguntará: ¿por qué? Normalmente, en tales casos, los consultores de DevOps responden: porque todos lo hacen. Si el director es verdaderamente astuto, dirá: ¿y qué? Y así terminará el diálogo. Yo respondería: porque en la empresa hay cuatro cuellos de botella: Fred, Lou, Suzy y Jane. Para institucionalizar su conocimiento, primero es necesario introducir Slack. Todos sus wikis son un completo disparate, porque nadie sabe que existen. Si el equipo de ingenieros trabaja tanto en desarrollo externo como interno, todos deben saber que pueden dirigirse al equipo de desarrollo externo o al equipo de infraestructura con preguntas. Es entonces cuando Lou o Fred probablemente tendrán tiempo para conectarse al wiki. Luego, en Slack, alguien puede preguntar por qué, digamos, el paso 5 no funciona. Y entonces Lou o Fred corregirán la instrucción en el wiki. Si se establece este proceso, muchas cosas se solucionarán por sí solas.
Aquí está mi idea principal: para recomendar alguna tecnología avanzada, primero hay que poner en orden la base para ellas, y esto se puede lograr con las soluciones de baja tecnología que acabo de describir. Si se empieza con tecnologías avanzadas y no se explica por qué son necesarias, por lo general, esto no termina bien. Uno de nuestros clientes utiliza Azure ML, una solución muy económica y simple. Aproximadamente el 30% de las preguntas ya eran respondidas por la máquina autodidacta. Y esta herramienta fue desarrollada por operadores que no estaban en el campo de la ciencia de datos, estadística o matemáticas. Esto es indicativo. El costo de esta solución es mínimo.
4. Hacks de colaboración
El cuarto arquetipo consiste en luchar contra la aislamiento. La mayoría de las personas ya lo sabe: la aislamiento genera hostilidad. Si cada departamento está en su propio piso y las personas apenas se cruzan, salvo en el ascensor, la enemistad entre ellos surge con mucha facilidad. Por el contrario, si las personas están en la misma sala, la hostilidad se desvanece de inmediato. Cuando alguien lanza una acusación general, como que una cierta interfaz nunca funciona, no hay nada más sencillo que deconstruir esa acusación. A los programadores que han creado la interfaz solo les basta empezar a hacer preguntas concretas y pronto se verá que, por ejemplo, el usuario simplemente utilizó incorrectamente la herramienta.
Hay muchas maneras de superar la aislamiento. En una ocasión, me pidieron que asesorara a un banco en Australia, pero me negué a hacerlo porque tengo dos hijos y una esposa. Todo lo que pude hacer fue recomendarles el storytelling gráfico. Es algo que demuestra funcionar. Otra forma interesante es las reuniones en formato lean coffee. En una gran organización, es una excelente opción para la difusión del conocimiento. Además, se pueden realizar devopsdays internos, hackatones, y demás.
5. Coaching Kata
Como ya advertí al principio, hoy no hablaré de esto. Si les interesa, pueden ver .
También hay una buena charla sobre este tema de Mike Rother:
6. Orientado al mercado: organización orientada al mercado
Aquí hay diferentes problemas. Por ejemplo, personas "I", personas "T" y personas "E". Las personas "I" son aquellas que solo se dedican a algo. Por lo general, existen en organizaciones con departamentos aislados. "T" es cuando una persona sabe mucho sobre algo específico, pero también se destaca en algunas otras áreas. "E" o incluso "peina" es cuando una persona tiene muchas habilidades.
Aquí se aplica la ley de Conway (), que se puede expresar de manera simplificada así: si tres equipos trabajan en un compilador, al final se obtendrá un compilador en tres partes. Por lo tanto, si dentro de una organización hay un alto nivel de aislamiento, incluso Kubernetes, Circuit breaker, API extensibility y otras cosas de moda en esa organización estarán organizadas de la misma manera que la propia organización. Estrictamente según Conway y en desacato a 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 funcionalmente orientada. El segundo tipo, que es el peor, es la arquitectura matricial, donde hay un caos de las dos anteriores. El tercero es lo que se observa en la mayoría de las startups, y las grandes empresas también intentan alinearse a este tipo. Es una organización orientada al mercado. Aquí se optimiza para lograr la respuesta más rápida a las consultas de los clientes. A veces se le llama organización plana.
Esta estructura se describe de muchas maneras, a mí me gusta la formulación build/run teams, en Amazon se llama two pizza teams. En esta estructura, todas las personas del tipo 'I' se agrupan en torno a un servicio, y poco a poco se acercan al tipo 'T', y si hay una buena gestión, pueden incluso llegar a ser 'E'. El primer contraargumento aquí es que en esta estructura hay elementos innecesarios. ¿Por qué necesita un probador en cada departamento, si se puede tener un departamento especial de pruebas? A lo que respondo: los gastos innecesarios en este caso son el precio a pagar para que en el futuro toda la organización se convierta en 'E'. En esta estructura, el probador gradualmente aprende sobre redes, arquitectura, diseño, etc. Al final, cada miembro de la organización se convierte en un experto en todo lo que sucede en ella. Si desea saber cómo funciona este esquema en la industria, lea .
7. Shift-left auditors: auditoría en las etapas tempranas del ciclo. Cumplimiento de las normas de seguridad a la vista
Esto es cuando tus acciones no superan, por así decirlo, la prueba del olfato. La gente que trabaja para ti no es tonta. Si, como en el ejemplo anterior, han estado clasificando todo como minor/no impact, esto ha durado tres años y nadie ha notado nada, todos saben que el sistema no funciona. O otro ejemplo: el consejo de cambios (change advisory board), donde cada miércoles se deben presentar informes. Ahí trabaja un grupo de personas (que, por cierto, no están muy bien remuneradas) que en teoría deberían saber cómo funciona el sistema en su conjunto. Y en los últimos cinco años, probablemente hayas notado que nuestros sistemas son increíblemente complejos. Y cinco o seis personas deben tomar decisiones sobre un cambio que ellos no han propuesto y del que no saben nada.
Por supuesto, este enfoque no funciona. Tengo que deshacerme de estas cosas porque esas personas no protegen el sistema. La decisión debe ser tomada por el mismo equipo, porque el equipo debe ser responsable de ella. De lo contrario, se presenta una situación paradójica en la que un gerente, que jamás ha escrito código en su vida, le dice a un programador cuánto tiempo debería llevar escribir un código. En una empresa en la que trabajé, había 7 consejos diferentes que revisaban cada cambio, incluido el consejo de arquitectura, de productos, etc. Incluso había un período de espera obligatorio, aunque un empleado me dijo que durante diez años de trabajo, nadie había rechazado en ese período obligatorio los cambios propuestos por esta persona.
Es necesario invitar a los auditores, no deshacerse de ellos. Diles que estás escribiendo contenedores binarios inmutables que, si pasan todas las pruebas, permanecen inalterados para siempre. Explícales que tienes pipeline as code y aclara lo que esto significa. Muéstrales el siguiente esquema: un binary inmutable solo de lectura en un contenedor que pasa todas las pruebas de vulnerabilidad; y luego, no solo nadie lo toca, ni siquiera el sistema que crea el pipeline, ya que este también se crea dinámicamente. Tengo clientes, Capital One, que utilizan Vault para crear algo parecido a un blockchain. No es necesario mostrar al auditor las 'recetas' de Chef, basta con mostrar el blockchain, que deja claro lo que ocurrió con el ticket de Jira en producción y quién es responsable de él.
Según , creado en 2018 por Sonatype, en 2017 hubo 87 mil millones de solicitudes de descarga de OSS.
Las pérdidas ocasionadas por vulnerabilidades son exorbitantemente altas. Además, las cifras que ves arriba no incluyen los costos alternativos. En pocas palabras, ¿qué es DevSecOps? Quiero aclarar que no me interesan las discusiones sobre cuán acertado es este nombre. La cuestión es que, dado que DevOps fue bastante exitoso, es necesario intentar añadir seguridad a este pipeline.
Un ejemplo de tal secuencia:
No es una recomendación de productos específicos, aunque me gusten todos. Los menciono como un ejemplo para mostrar que el DevOps, originalmente basado en la paradigmática de la organización industrial, permite automatizar cada etapa del trabajo sobre el producto.
Y no hay ninguna razón por la que no podamos aplicar el mismo enfoque a la seguridad.
Summary
Como conclusión, ofreceré algunos consejos para DevSecOps. Es fundamental incluir a auditores en el proceso de creación de sus sistemas y dedicar tiempo a su capacitación. Se debe colaborar con los auditores. Además, hay que mantener una lucha absolutamente rigurosa contra las falsas alarmas. Incluso con la herramienta de escaneo de vulnerabilidades más cara, se pueden crear hábitos extremadamente perjudiciales para sus desarrolladores si no se comprende la relación entre señales y ruido. Los desarrolladores se verán abrumados por eventos y simplemente los eliminarán. Si ha oído hablar de la historia de Equifax, eso es aproximadamente lo que sucedió, se ignoró la señal de más alto nivel de peligro. Además, se deben explicar las vulnerabilidades de manera que quede claro cómo afectan al negocio. Por ejemplo, se puede decir que esta es la misma vulnerabilidad que en la historia de Equifax. Las vulnerabilidades de seguridad deben ser tratadas como otros problemas de software, es decir, deben ser integradas en el proceso general de DevOps. Se debe trabajar con ellas a través de Jira, Kanban, etc. Los desarrolladores no deben pensar que será alguien más quien se encargue, por el contrario, esto debe ser responsabilidad de todos. Finalmente, se debe invertir esfuerzo en capacitar a las personas.
Enlaces útiles
Aquí hay algunas charlas de la conferencia DevOops que pueden parecerle útiles:
- Serguéi Berdnikov, Artyom Kalichkin — Historia de éxito, o «Dev+DevOps+Ops» (, )
- Baruj Sadogurski, Leonid Igolnik — DevOps a gran escala: tragedia griega en tres actos (, )
- Alexander Titov, Kirill Tolkachyov —
- Timothy Lister —
Eche un vistazo a DevOops 2020 Moscú — también hay muchas cosas interesantes allí.
Fuente: habr.com
