Han pasado casi dos años desde que escribí la respuesta después del descanso. En ese tiempo he estado ayudando a dirigir “DevOps” en Twitch, una compañía de Amazon. Además, recientemente se han publicado algunos libros excelentes (en 2016) sobre este tema: Google SRE, Manual de DevOps, DevOps Tooklit 2.0 e Infraestructura como código. Por supuesto, también hay clásicos más antiguos en esta área, específicamente la integración continua y la entrega continua.
Aquí hay algunos puntos que agregaría a los “conceptos básicos” y la vista tradicional que proporcioné anteriormente:
- “DevOps” y “SRE” están creciendo en popularidad y casi están tomando sus propias vidas, por lo que las personas definirán los términos de muchas maneras. El manual DevOps de Gene Kim hace un buen trabajo al describir la historia de la palabra DevOps. Del mismo modo, el libro de Google SRE describe lo que significa SRE en Google.
- Sin embargo, hay un cambio de imagen más grande que me gustaría señalar. Y creo que es un cambio similar a Agile, Scrum, etc., un cambio de mentalidad ENORME. Creo que está plasmado en estas dos frases 1.) “Lo construyes, lo ejecutas” (Netflix) y 2.) “SRE es lo que obtienes cuando le pides a un ingeniero de software que realice un trabajo Ops tradicional” (algo así – también conocido como mucha automatización y autoservicio).
- Este nuevo mundo crea varios cambios alucinantes (que voy a llevar a su extremo para el impacto).
- No hay más operaciones OPS ni organización de NOC : si usa un proveedor de Cloud, la función SA desaparece, si pone a todos los Devs de guardia, el NOC desaparece: lo construye, lo ejecuta.
- No hay más organización de control de calidad (o al menos es muy pequeña): los desarrolladores escriben ~ 90% de las pruebas automatizadas (Unidad e integración), tal vez el control de calidad realiza el 10% restante de la automatización de la interfaz de usuario anterior y las pruebas exploratorias manuales. La opinión tradicional de que necesita control de calidad porque no se puede confiar en los desarrolladores para probar su propio código no se aplica: el 90% de la prueba es suya y si el F * está arriba, están de guardia.
- No hay proceso de control de cambios. De hecho, un proceso de control de cambios es en realidad contraproducente: pone en cola los cambios haciéndolos más grandes y más riesgosos. Una tubería de implementación reflexiva, resistencia y retroalimentación rápida es más efectiva.
- Desarrolladores “Full-Stack” Por supuesto, esto pone mucha más carga y responsabilidad en los desarrolladores. Esto le da un significado completamente nuevo a “Full Stack”: no solo front-end, back-end, sino también AWS, QA y Ops (de guardia).
- Por supuesto, a medida que crezca, puede agregar algo de especialización. Pero lo harías dentro de los equipos de productos.
- Y sí, también debe tener algunos equipos de desarrollo centrados en “servicios compartidos” o productos de “plataforma”.
- Sin embargo, parte de este cambio cultural es adoptar conceptos de desarrollo de código abierto internamente : ¡ cualquiera puede cambiar el código de cualquier otra persona! No más dependencias, no más colas. Los equipos de productos deben ser “autónomos”. Si necesitan un cambio a un producto dependiente, hacen una solicitud de extracción, realizan el cambio, pasan por una revisión de código, pruebas automatizadas y su implementación, ¡potencialmente ese mismo día!
- Si es necesario agrupar los cambios para su comercialización en un “lanzamiento” para que todos puedan ser anunciados y lanzados en el evento anual “press-the-flesh” (CES, Twitchcon, AWS Invent), se “lanzan en la oscuridad” de forma incremental tal como están. terminado. Han estado “tomando tráfico” durante meses, pero ocultos detrás de API y banderas de características para que el público en general no pueda verlos. Toda su gloria ha sido expuesta en la “alimentación de perros” y los entornos de prueba automatizados. Todo esto reduce notablemente tanto el RIESGO DE HORARIOS como el riesgo de Incidentes.
¡Guauu! El cambio es bastante interesante. ¡Lo que comenzó como un software de desarrollo de equipos de desarrollo para Ops (a continuación) se ha cambiado a algo notablemente diferente!
- Con el auge de las redes definidas por software, ¿tiene sentido financiero continuar buscando la certificación de Cisco?
- ¿Cuál es la diferencia entre TI e ingeniería de software?
- Codificación Bootcamp vs grado de 4 años (ingeniería de software, informática)? ¿Cuáles son los costos y beneficios de ambos? ¿Cuál podría ser mejor?
- ¿Qué es el software de código abierto? ¿Es malo para su teléfono y hay un opuesto?
- ¿Cuáles son los cursos más importantes en un plan de estudios de CS para un ingeniero de software?
*** Marzo 2015 Anser debajo ***
Solía dirigir el equipo de DevOps en eBay. Para mí, “DevOps” es un equipo de desarrollo de software que apoya a la organización de Operaciones. Para una gran empresa web como eBay, hay una sorprendente cantidad de software que se utiliza para apoyar las “operaciones” de la empresa.
Si aún no está familiarizado con él, debería familiarizarse con ITIL. ITIL describe los diversos procesos en torno a las operaciones.
Construir y liberar
- Build : es el proceso de integración, creación y compilación del software que se produce. Para grandes equipos de software, generalmente hay un proceso de integración continuo donde los desarrolladores de software registran sus cambios, y si alguien interrumpe la compilación, debe abordarse. El proceso de integración puede tomar mucha potencia de procesamiento y varias horas. Esta infraestructura necesita ser monitoreada y optimizada. Comúnmente se utilizan productos como ClearCase, Maven o GitHub para este proceso. (También puede haber un conjunto de pruebas unitarias automatizadas que se ejecutan contra esta “compilación”).
- Lanzamiento : una vez que el software se “verifica”, se integra sin errores, se pasan las pruebas automáticas y el control de calidad lo aprueba: el software está listo para implementarse o lanzarse a producción. Esto también puede ser un proceso bastante extenso. Cuando estaba en eBay, teníamos 15,000 servidores en los que implementamos código. Los servidores se agruparon en “agrupaciones” lógicas para redundancia. Implementaríamos código nuevo de forma incremental y “retrocederíamos” si hubiera problemas. Para facilitar esto, utilizamos el software Tivoli de IBM con un software personalizado además de eso.
- Fiabilidad del sitio : tiende a ser un equipo y proceso diferente dentro de las operaciones. Si bien lo anterior está tratando de llevar el software al sitio web, el equipo de Site Reliability está tratando de mantener el sitio web en funcionamiento con la mayor cantidad de nueves (99.99 +%) posible. Entonces, los equipos, o procesos, están en desacuerdo. En eBay, este equipo de operaciones se denominó “El NOC”, el Centro de Operaciones de Red. Esta fue una operación bastante impresionante: una sala llena de monitores de pantalla grande con datos corriendo a través de ellos. Incluso los programas de noticias se muestran porque ciertos “eventos” en el mundo pueden crear picos en el sitio web. Todo esto requiere software. Software que está “monitoreando” el sitio web y los sistemas. Software que “alerta” cuando las cosas salen mal. Software que clasifica alertas para determinar cuáles son importantes. Software que convierte las alertas en “incidentes”. Software que le ayuda a gestionar incidentes para “restaurar el servicio”. Y software para análisis de causa raíz y “gestión de problemas”. ¡Uf! Eso es mucho software.
- SA y aprovisionamiento : hay otra área que es importante para DevOps que no mencionó. Especialmente con la popularidad de “Cloud Computing”, esta es la implementación y configuración “fluida” del hardware. Esto se conoce comúnmente como “aprovisionamiento”. Esto implica “administración de sistemas” e intenta automatizar muchas de sus tareas. Piense en el EC2 de Amazon y cómo puede poner en funcionamiento una “instancia” en minutos a través de una interfaz web simple y unos pocos clics. En el viejo mundo, esto llevó numerosos “tickets” a las Operaciones, potencialmente el pedido de nuevo hardware y varias aprobaciones y cierres de sesión. ¡Este proceso puede llevar meses! Ahora lleva unos minutos. Pero todo es facilitado por los equipos de desarrollo de software y software, “DevOps”.
- Facturación y administración : además, con la llegada de Cloud Computing y los servicios de computación en la nube, los equipos de DevOps han tenido que encontrar formas de instrumentar sistemas, monitorear su utilización y determinar algoritmos para cobrar a los clientes por su utilización.
Creo que eso lo cubre. Espero que esto ayude…