Dous nunha caixa (se podes) e todos en documentación (sempre).
Nun contexto de TI, "dous nunha caixa" refírese a dous servidores ou compoñentes que están deseñados para traballar xuntos para proporcionar redundancia e maior fiabilidade. Esta configuración pode garantir que se un compoñente falla, o outro se faga cargo das súas operacións, mantendo así a continuidade do servizo. O obxectivo de ter "dous nunha caixa" é proporcionar alta dispoñibilidade e recuperación ante desastres. Isto tamén se aplica aos roles humanos nunha organización; porén, raramente se implementa.
Vexamos un exemplo relevante de Analytics. Probablemente todos coñezamos a unha persoa da nosa empresa ou organización por nome que é a persoa de referencia para Analytics. Son os que teñen informes ou paneis de control que levan o seu nome: Informe de Mike ou Panel de control de Jane. Por suposto, hai outras persoas que saben analíticas, pero estes son os verdadeiros campións que parecen saber facer as cousas máis difíciles e superar os prazos. O problema é que esta xente está soa. En moitos casos, baixo presión, non traballan con ninguén, xa que iso pode ralentizalos e aquí é onde comeza o problema. Nunca pensamos que imos perder a esta persoa. Absterei do típico “digamos que son atropelados por un autobús” ou usar un exemplo aproveitando as oportunidades actuais do mercado laboral e dicir algo positivo como “¡gañaron a lotería!”, porque todos debemos facer a nosa parte para ser positivos. estes días.
The Story
Chega o luns pola mañá e o noso experto en análise e campión MJ presentou a súa dimisión. MJ gañou a lotería e xa deixou o país sen preocuparse no mundo. O equipo e as persoas que coñecen a MJ están emocionados e celosos, pero o traballo debe ir. Agora é cando o valor e a realidade do que facía MJ está a piques de entenderse. MJ foi o responsable da publicación final e da validación das analíticas. Sempre parecían ser capaces de mellorar a eficiencia ou facer ese cambio difícil antes de proporcionar as analíticas a todos. A ninguén lle importaba realmente como se fixera e estaba seguro de que acababa de suceder, e MJ era unha estrela de rock individual de Analytics, polo que se outorgou un nivel de autonomía. Agora, cando o equipo comeza a recoller as pezas, as solicitudes, os problemas cotiáns, as solicitudes de modificación quedan sen perder e comezan a revolverse. Os informes/Paneis de control atópanse en estados descoñecidos; algúns activos non se actualizaron durante a fin de semana, e non sabemos por que; a xente pregunta que está a pasar e cando se arranxarán as cousas, as edicións que MJ dixo que se fixeron non aparecen e non temos idea de por que. O equipo pinta mal. É un desastre e agora todos odiamos a MJ.
As leccións
Hai algunhas cousas fáciles e obvias para levar.
- Nunca permita que unha persoa traballe só. Parece ben, pero en equipos áxiles máis pequenos, non temos tempo nin xente para que isto suceda. A xente vai e vén, as tarefas son moitas, polo que é dividir e vencer en nome da produtividade.
- Cada un debe compartir o seu coñecemento. Tamén soa ben, pero estamos compartindo coa persoa ou persoas adecuadas? Teña en conta que moitos gañadores da lotería son compañeiros de traballo. Facer sesións de intercambio de coñecemento tamén quita tempo ás tarefas e a maioría da xente só inviste en habilidades e coñecementos xusto a tempo cando é necesario.
Entón, cales son algunhas solucións reais que todos poden implementar e respaldar?
Comecemos coa xestión da configuración. Usaremos isto como termo xeral para varios temas similares.
- Xestión do cambio: O proceso de planificación, implementación e control de cambios nos sistemas de software de forma estruturada e sistemática. Este proceso ten como obxectivo garantir que os cambios se realicen de forma controlada e eficiente (con capacidade de reversión), coa mínima interrupción do sistema existente e o máximo beneficio para a organización.
- Xestión de Proxectos: A planificación, organización e control dos proxectos de desenvolvemento de software para garantir que se completan a tempo, dentro do orzamento e cos estándares de calidade desexados. Implica a coordinación de recursos, actividades e tarefas ao longo do ciclo de vida do desenvolvemento de software para acadar os obxectivos do proxecto e entregar o produto de software a tempo.
- Integración continua e entrega continua (CI/CD): O proceso de automatización da construción, proba e implantación de software. A integración continua require combinar regularmente os cambios de código nun repositorio compartido e executar probas automatizadas para detectar erros no inicio do proceso de desenvolvemento. A entrega/implementación continua implica a liberación automática de cambios de código probados e validados na produción, o que permite lanzamentos rápidos e frecuentes de novas funcións e melloras.
- Control de versións: O proceso de xestión de cambios no código fonte e outros artefactos de software ao longo do tempo utilizando ferramentas de software especializadas. Permite aos desenvolvedores colaborar nunha base de código, manter un historial completo de cambios e experimentar con novas funcións sen afectar á base de código principal.
Todo o anterior refírense a boas prácticas de desenvolvemento de software. As analíticas que impulsan e dirixan o negocio non merecen menos, xa que son unha misión crítica para a toma de decisións. Todos os recursos analíticos (traballos ETL, definicións semánticas, definicións de métricas, informes, paneis de control, historias, etc.) son só fragmentos de código cunha interface visual para o deseño e os cambios aparentemente menores poden causar estragos nas operacións.
Usar a Xestión da configuración cúbrenos para seguir funcionando en bo estado. Os activos son versionados para que poidamos ver o que pasou na súa vida útil, sabemos quen está a traballar en que xunto cos progresos realizados e os prazos, e sabemos que a produción continuará. O que non está cuberto por ningún proceso puro é a transferencia de coñecemento e a comprensión de por que as cousas son como son.
Cada sistema, base de datos e ferramenta de análise teñen as súas propias peculiaridades. Cousas que os fan ir rápido ou lento, elementos que os fan comportarse dun xeito determinado ou producir un resultado desexado. Estes poden ser axustes a nivel de sistema ou global ou cousas dentro do deseño de activos que os fan funcionar como deberían. O problema é que a maioría destas cousas apréndense co paso do tempo e non sempre hai un lugar onde documentalas. Aínda que pasamos a sistemas de nube onde xa non controlamos como se executa a aplicación e confiamos no provedor para facelo o máis rápido posible, o axuste das definicións continúa nos nosos activos para desbloquear exactamente o que buscamos. Este coñecemento é o que hai que capturar e compartir poñéndoo a disposición dos demais. Este coñecemento ten que ser esixido como parte da documentación dos activos e facer parte integrante do control de versións e do proceso de verificación e aprobación de CI/CD e, nalgúns casos, incluso como parte dunha lista de verificación antes de publicar as cousas que facer e non. facer.
Non hai respostas máxicas nin intelixencia artificial para cubrir atallos nos nosos procesos de análise ou a súa falta. Independentemente do tamaño do equipo que faga fluír os datos e as analíticas, é imprescindible un investimento nun sistema para rastrexar os cambios, facer versións de todos os activos e axudar a documentar o proceso de desenvolvemento e capturar coñecementos. O investimento en procesos e tempo por adiantado aforrará unha tonelada de tempo perdido despois de descubrir cousas para manter un estado saudable das nosas analíticas. As cousas pasan e é mellor ter unha póliza de seguro para MJs e outros gañadores da lotería.
