Administrador de sistemas ágil y devops: ¿cómo lograrlo? [cerrado]

Hoy en día, la administración de sistemas ágiles y los devops son algunos de los temas de mayor tendencia con respecto a la administración y operaciones de sistemas. Ambos conceptos se centran principalmente en cerrar la brecha entre las operaciones / administradores de sistemas y los proyectos (desarrolladores, negocios, etc.). Incluso si nunca escuchó sobre el concepto de DevOps, estoy seguro de que este tema es su preocupación también.

Entonces, ¿qué herramientas y técnicas utilizas para lograr devops en tus empresas? Estoy particularmente interesado en temas como la gestión del cambio, la integración continua y la automatización, pero no solo en estos temas. Por favor comparte tus pensamientos. Tengo muchas ganas de leer sus respuestas / opiniones :)

• svn / git - control de revisión, obviamente.

• trac / redmine / jira - venta de entradas.

• cobbler: para el aprovisionamiento del servidor del sistema operativo base. Cobbler es un producto enfocado en la familia redhat, pero estoy seguro de que hay algo similar para debian / ubuntu. De manera similar, la mayoría de las compañías de "panel de control en la nube" como RightScale le proporcionarán esto. La palabra clave aquí es "JEOS" o "sistema operativo suficiente". Mi ruta es usar la línea "% packages --nobase" en mis kickstarts y luego construir mi pila específica a través de ...

• marioneta / chef - para la gestión de la configuración y la aplicación de la coherencia Aquí también hay otras opciones, es más importante que uses una que la que. Un truco que he encontrado particularmente importante es almacenar las configuraciones en el mismo sistema de control de versiones que usan los desarrolladores. Esto ayuda a unir el flujo de trabajo de los dos equipos y hacerlo visible el uno al otro.

• func (o capistrano o cluster-ssh): para ejecutar el script de implementación en el clúster. El truco aquí es convertirlo en algo que los desarrolladores senior puedan ejecutar para impulsar nuevas cosas en vivo y las soluciones inevitables.
  Este es realmente el núcleo de los desarrolladores, lo que permite a los desarrolladores romper y reparar el entorno. Muchos administradores de sistemas están demasiado hambrientos de poder como para dejarlos ir, o su administración aún funciona con la noción errónea de que los administradores de sistemas deberían estar vigilando a los desarrolladores (como si pudiéramos leer la mitad de lo que están haciendo).

• cacti / ganglia / collectd / munin - los gráficos son muuuuy clave. Es el valor comercial de las métricas con el valor humano de las imágenes simples. Correlacionar la marca de tiempo de los impulsos de código con la marca de tiempo de los cambios en los gráficos es inmensamente valioso para solucionar problemas de regresión de rendimiento y ver hechos reales sobre decisiones de rendimiento. Hay un punto clave aquí en que los gráficos deben ser fáciles de ver y usar por los desarrolladores y su administración debe esperar de ellos.

• nagios / zabbix / smokeping / etc - monitoreo de cosas del servidor y métricas de rendimiento tipo "página base". Nuevamente los gráficos son clave. Estos son más para el lado de operaciones del equipo.

• gomez / keynote / browsermob: monitoreo externo del rendimiento completo del navegador, teniendo en cuenta servicios de terceros, CDN y problemas de tiempo de renderizado. Estos son más para el lado de desarrollo del equipo.

Esa es una mezcla de herramientas y técnicas, concéntrese en las técnicas. Específicamente, el cambio en la mentalidad del lado "administrador del sistema" de los devops de "admin" a "operaciones". Se trata de habilitar a los desarrolladores. Permitiéndoles hacer cosas, permitiéndoles arreglar cosas, permitiéndoles ver hechos / métricas / gráficos reales sobre lo que hicieron. Por el contrario, los desarrolladores deben aceptar que han sido habilitados y en realidad hacen el trabajo de observar las tendencias de rendimiento, depurar problemas y pensar no solo en las características, sino también en cómo implementarlas y cómo afectarán la salud de todo el sistema / entorno .

Estamos trabajando para hacer esto en National Instruments. Puede leer más sobre lo que estamos haciendo en http://dev2ops.org/blog/2010/4/27/qa-ernest-mueller-on-bringing-agile-to-operations.html

La combinación de herramientas que Cagenut menciona aquí básicamente va en la dirección en que nos estamos moviendo aquí.

El mejor enfoque es comprender el entorno en el que trabaja. Comience hablando con los desarrolladores y gerentes. Trate de tenerlos a bordo y rebote ideas de ellos. Lo más probable es que tengan una buena idea de cómo se ejecutan las cosas y si sus ideas para introducir devops causarán algún problema.

A partir de ahí, comience a buscar aplicaciones y preséntelas una por una para resolver problemas.

Si bien las herramientas y técnicas son importantes, la ruta crítica es en colaboración en toda la organización. En estos días de operaciones es operaciones comerciales. Etsy muestra cambios en los ingresos en sus paneles, visibles para todos.