Trate su código de automatización de TI también como ganado.
La TI debe adoptar la estandarización del código que la hace funcionar o correr el riesgo de crear sistemas que desvíen los beneficios financieros y de eficacia de la automatización de la TI.
Pasé casi una década desarrollando software. Software integrado. Software web. Software cliente-servidor. Software de middleware y mainframe. He escrito código profesionalmente en nueve lenguajes diferentes. Lo interesante es que no recuerdo haber utilizado más de dos idiomas en la misma organización.
La mayoría de las organizaciones empresariales estandarizan no sólo servidores, plataformas y marcos de trabajo, sino también lenguajes. Existe un objetivo de mantenibilidad para un software que tiene una vida útil de más de minutos y a veces se cuenta en décadas. La mantenibilidad es la característica del software que permite que alguien más lo adopte y le brinde soporte durante todo su ciclo de vida, independientemente de cómo se pueda medir esa vida útil. Esto se debe a menudo a la rotación de desarrolladores y a la disponibilidad en el mercado de conocimientos del lenguaje, así como a los costos de capacitación y mantenimiento general. Como regla general, las empresas estandarizan los lenguajes de programación.
Esto es un anatema para las tendencias actuales en microservicios y computación sin servidor que promocionan como beneficio su capacidad de soportar un conjunto muy diverso (políglota) de lenguajes. Bob y su equipo pueden escribir en Go mientras Alice y su equipo desarrollan en C o Java o Lambda. Si bien es una ventaja para los desarrolladores (que tienen su lenguaje favorito), no es tan bueno para las organizaciones empresariales que necesitan mantener ese software a lo largo del tiempo. Las API permiten su integración y uso, lo que hace que su lenguaje de implementación sea en gran medida irrelevante en términos de desarrollo de aplicação , pero en una empresa el código subyacente aún necesita mantenimiento.
Cuando se trata de la automatización de TI (la transformación digital interna que ocurre en el lado de producción de la empresa), es importante que las organizaciones reconozcan no solo los beneficios de la estandarización en los scripts y sistemas que se construyen para respaldarla, sino también los riesgos de no hacerlo. Porque no estás construyendo estos sistemas con la intención de desecharlos la próxima semana, el próximo mes o incluso el próximo año. Son una inversión a largo plazo que respaldará la digitalización de la implementación en los próximos años. Esto significa sentar una base flexible pero firme que se base en las mejores prácticas aprendidas durante décadas por los desarrolladores de aplicaciones en empresas de todo el mundo, la primera de las cuales es la estandarización.
1.Mantenibilidad
Sé que a ti te gusta escribir en PERL, pero todos los demás usan Python. Desarrollar la automatización en su lenguaje favorito lo convierte en su mascota, lo que significa que nadie más podrá mantenerlo en el futuro. Eso es malo para ti, porque te quedarás atrapado con esa cosa durante años, igual que el pez dorado que le rogaste a tus padres cuando tenías ocho años. Eso es malo para la organización porque si se muda, se quedarán atrapados con un código que no pueden mantener y podría ser difícil brindar soporte. Una encuesta de 2016 realizada por SIG y O'Reilly descubrió que "el 70 % de los encuestados cree que la capacidad de mantenimiento es el aspecto más importante del código a medir, incluso en comparación con el rendimiento o la seguridad".
Es muy importante. Considere los scripts y sistemas como recursos compartidos que la mayoría de las personas en TI pueden modificar y soportar fácilmente ahora y en el futuro.
2.Compatibilidad
A medida que se implementan más y más servicios de TI como software, crece la tarea de mantenerlo actualizado y compatible con otros sistemas. Si cree que las API REST eliminan el problema de la “compatibilidad con versiones anteriores”, piénselo nuevamente. Las API son productos (o deberían serlo) y, por lo tanto, también están en constante evolución. Y es peor en “la red”, donde hay diferencias incluso dentro de la misma línea de productos, con diferencias de API de una versión a otra que hacen de la estandarización una tarea titánica. Es un problema tan extendido que la estandarización de API fue el tercer desafío tecnológico que se debe resolver en los próximos años según uno de cada cuatro encuestados en el informe State of API 2016 de Smart Bear .
Y debido a que muchos de los lenguajes que usamos en TI son interpretados, los cambios de una versión a otra pueden destruir sistemas y scripts de automatización cuidadosamente diseñados. Los cambios de una versión de node.js a otra pueden tener un impacto profundamente negativo, desde romper un script hasta un comportamiento inesperado. La estandarización de versiones estables de entornos y lenguajes de scripting ayudará a minimizar el impacto de dichos cambios.
Y todavía tendrás que administrar parches y actualizaciones para cada sistema subyacente que impulsa esa automatización, así que cuanto menos, mejor.
3.Solución de problemas
Descartar la estandarización implica problemas para la resolución de problemas. Esto es particularmente importante si está migrando a una métrica basada en el tiempo de resolución para los KPI de TI . Cuanto más tiempo lleve encontrar el problema, peor parecerá esa métrica. La estandarización es un componente importante para reducir el tiempo de resolución. Si Bob es el único experto en Python del personal y está de vacaciones (y no se puede contactar con él) y su script falla, quien esté encargado de solucionar el problema tendrá que afrontar una semana muy larga. Cuando se alienta al departamento de TI a utilizar su lenguaje favorito, se limita severamente la capacidad de otros para detectar y resolver problemas. Incluso si Bob no está de vacaciones y no puede encontrar el problema, hay pocos que puedan ayudar.
Esta no es un área en la que quieras meterte. Según InitialState , lleva 30 veces más tiempo corregir un error que escribir una línea de código. Puedes visualizar el dinero entrando lentamente en la trituradora mientras luchas por encontrar un error en el código con el que no estás familiarizado y luego solucionarlo. No es una imagen bonita No se puede eliminar el costo de la resolución de problemas, pero se puede limitar eliminando el tiempo adicional que requiere alguien que, en primer lugar, no conoce el idioma. En producción, el tiempo es dinero, por lo que cualquier cosa que pueda hacer para reducir el tiempo de resolución es muy importante.
Es por eso que, a medida que TI adopta lentamente lenguajes de programación, herramientas y sistemas, no es una mala idea sincronizarse con el desarrollo de aplicaciones. Si TI se estandariza en los mismos sistemas y lenguajes (o al menos algunos de ellos), se gana una legión de expertos capaces de ayudar en la resolución de problemas y otros procesos relacionados con el desarrollo, como las revisiones de código. Porque estás implementando revisiones de código como un medio para encontrar errores antes de que causen problemas, ¿verdad? ¿Bien?
Se cita la estandarización como un medio para combatir el aumento de los costos y ciertamente es un contribuyente clave a tales esfuerzos. Pero la estandarización también tiene otros beneficios, entre ellos la minimización de la deuda técnica, la reducción del tiempo de resolución y la simplificación del mantenimiento operativo diario. No estandarizar en absoluto ciertamente tiene el efecto opuesto en los presupuestos y el tiempo al introducir complejidad y cuellos de botella que anulan los beneficios de la automatización e impiden que las empresas obtengan las ganancias y la productividad que necesitan para crecer. A medida que comienza o continúa su recorrido de automatización de TI, recuerde tratar esos scripts y sistemas más como ganado y no como mascotas. Porque las mascotas requieren una atención personal y constante que IT no puede permitirse en el futuro.