DEV Community: Juan A. Reséndiz

[Opinión] El problema del liderazgo en los equipos de tecnología.

Juan A. Reséndiz — Mon, 02 Aug 2021 23:27:45 +0000

Esto es mi opinión, la comparto y espero poder generar conciencia y un poco de debate sano; con la finalidad de mejorar o bien, comenzar con el camino de un liderazgo integral en la industria de tecnología.

Conforme pasan los años y uno va creciendo en TI (hablando específicamente en la industria del Software) te das cuenta de las fuertes deficiencias en educación emocional, comunicación y resolución de conflictos que existen en la industria.

Desafortunadamente es algo de lo que pecamos muchos en el área, nuestro egoísmo y gatekeeping nos impiden buscar un crecimiento organizacional íntegro y orgánico sin tener que aspirar siempre a ser el mejor en todo.

Estos problemas permean mucho más allá cuando contamos con posiciones de liderazgo y nos deja con una gran deficiencia al intentar ser líderes de equipo.

Imaginemos la siguiente mezcla:

Gatekeeping
Sesgos personales
Poca educación emocional (empatía, tolerancia, respeto, etc)
Mala comunicación (timing, ortografía, tono de voz, etc)
Egoísmo

Es una exquisita combinación para el desastre.

¿Cuál podría ser el origen de este problema?

Esta es una excelente pregunta, y considero, no hay una respuesta correcta, si no, un universo de éstas.

Bajo mi perspectiva, uno de los principales factores viene desde la formación y perfil de áreas relacionadas a ingeniería.

En ciertas escuelas/empresas/bootcamps se nos enseña que:

"Somos los mejores"
"Podemos con todo lo que tenemos enfrente"
"Cómo sea, pero hazlo"
"Todos los egresados y egresadas de aquí terminan en las FAANG"
"Si X persona no sabe Y concepto, ¿Para qué lo quiero en mi equipo?"
"Necesito profesionales y especialistas, no code monkeys"

Estas y muchas otras frases las podemos encontrar en #TechTwitter (donde también hay MUCHO apoyo y pasión por querer cambiar esto),así como rondando en chats de algunas comunidades, Linkedin y hasta dentro de los mismos procesos de reclutamiento (si eres entrevistador o aplicante, te invito a analizarlo).

Este tipo de ideas durante nuestra etapa formativa, terminan por acentuar conductas, por ejemplo: elitismo, egoísmo, falta de empatía, un debate sesgado y acotado por nuestro mismo grupo social, etc; que pueden o van a perdurar por años, siempre y cuando no decidamos tomar conciencia, aceptar que se puede cambiar y actuar a nivel personal.

Ahora imagina que tu líder (tech lead, manager, líder de área, CTO, CEO, etc) comparte esas mismas ideas, esto termina por generar procesos con muchos sesgos y acentuar dichos comportamientos.

El resultado es un equipo fragmentado y una comunidad viciada con esas mismas ideas; brindando también inconformidad y alta rotación en los equipos.

Existe una solución o ¿cuál sería el camino más adecuado?

Esta pregunta, igual que la anterior, no tienen una respuesta única ni absoluta (porque se terminaría por polarizar, y no es el objetivo); sin embargo, hay caminos validados y documentados.

Es necesario comenzar con el proceso de deconstrucción como individuos (más aún los que estamos en posiciones de liderazgo), eso nos permitirá analizar y comprender mejor nuestros sesgos, fortalezas, debilidades y miedos (que se suelen reflejar en acciones que reprimen y limitan a nuestro equipo), y así comenzar a cuestionar si lo que somos es realmente lo que queremos tener en nuestra carrera profesional y mostrar como estandarte de un área.

Aceptar la enorme diversidad de opiniones y como cada una de estas son valiosas para el crecimiento integral de la comunidad, será uno de los pilares para lograr una comunicación sana dentro del equipo.

Estar abiertos como líderes del área a opiniones totalmente distantes de las nuestras, para comprenderlas y complementarlas o bien, incentivar el debate sano en los equipos a los que lleguemos a formar parte.

Cambiar la imposición por guía, fomentar la comunicación abierta, motivar la retroalimentación empática, incentivar el reconocimiento, invitar a cometer y aprender de los errores, son algunas de las muchas acciones que podemos tomar cuando estamos al frente de un equipo.

Quitarnos la idea y esa pasión por el control en cada uno de los procesos de nuestros equipos y comprender, que la diversidad ideológica nos permite un crecimiento integral, nos da una excelente oportunidad para crecer profesional y emocionalmente.

La educación emocional: una herramienta difícil de encontrar y a veces igual de complicado de desarrollar.

Estas famosas Soft Skills (también muy relacionadas con la educación emocional), pueden ser unos de los factores de diferenciación entre un excelente compañero de trabajo (ya sea líder o no) o bien, alguien a quien podemos apoyar e incentivar a crecer a la par con el resto del equipo o de la organización.

A título personal, estas habilidades me ha tocado desarrollarlas a través de procesos complejos (terapia, cometer errores, pérdidas, cambios de trabajo, etc), siendo mi experiencia sólo uno de los muchos caminos igual de válidos para lograrlo.

Lo más importante es desarrollar la humildad, cuestionar la formación/idea que tenemos de nosotros, buscando siempre nuestro crecimiento a la par de la comunidad.

Como líderes, debemos recordar que todos los seres humanos tenemos una gran cualidad: la vulnerabilidad; esta nos permite detectar nuestras fortalezas y debilidades, a pesar de lo amargo que puede llegar a ser reconocerla y afrontarla.

Terminaré por preguntarte: Y tú, ¿por donde comenzarás a cuestionarte y cuestionar los procesos e ideas que tienes a tu alrededor?

Le debo dinero al Banco de México: Negociando la deuda técnica.

Juan A. Reséndiz — Thu, 02 Jul 2020 18:34:44 +0000

Apenas llegué y ya estan lloviendo los golpes tickets

A todos nos ha pasado. Llegas a un nuevo equipo, una nueva empresa, startup o consultora y tu primer semana te asignan un bug.
¿Será mi novatada? ¿Por qué está pasando esto? Probablemente te harás miles de preguntas, pero hay algo común en ese comportamiento: la deuda técnica.

La deuda técnica se define como el trabajo adicional (o retrabajo) a una tarea o funcionalidad definida, regularmente por alguno de estos motivos (pueden ser más):

Un camino fácil (a veces hackish) Duck tape programmer
Optimización prematura
Mala definición o diseño
Acoplamiento con algún componente externo o interno
Falta de visión durante el refinamiento de la tarea

Este concepto tiene una analogía directa con la deuda monetaria en cualquier sistema financiero, es decir, si dicha deuda no se paga, esta seguirá generando intereses y dificultará su pago futuro o reimplementación, lo cual suele ser muy costoso por la posible pérdida de conocimiento.

Cabe destacar que, como cualquier deuda o préstamo que se pide al banco, siempre se puede negociar y dependerá del uso que decidamos darle.

Por ejemplo, podemos pedir un préstamo para poner un negocio y conforme tengamos cierta liquidez comenzar a pagarlo; o bien, irnos a un bar con nuestros amigos a gastarnos el ingreso recién generado.

La situación en la industria del software es la misma. No es malo tener deuda técnica, es malo cuándo no decides pagarla o la ignoras.

Hola, este software fue mio pero yo ya me fui

Todos hemos tocado ese punto donde tenemos sistemas legados, procesos completos de ingeniería que tienen áreas enormes de oportunidad pero por ser "viejos" son juzgados y vistos como el principal problema del mundo actual.

Un sistema legado es aquel que podemos clasificar como obsoleto, poco actualizado o bien, con visión distinta a lo que requiere el negocio actualmente. Muchos factores pueden hacer que un sistema sea clasificado o no como legado. Por ejemplo:

Falta de soporte de algún framework, biblioteca o lenguaje
Exceso de deuda técnica en el sistema
Actualización de los estándares bajo los que el sistema fue diseñado
Cambios en la estructura del negocio que impiden su actualización gradual
Las métricas sobre cambios o actualizaciones suelen ser muy costosas (relacionado al mismo tiempo a la deuda técnica)
Acoplamiento del proceso con algún hardware en específico y qué este haya sido deprecado

Estos solo son algunos de los muchos factores que pueden marcar como legado a un sistema.
Pero la pregunta del millón: ¿Debo reemplazar todo mi sistema y crearlo desde cero? ¿Puedo evitar tener un sistema legado?

Las respuestas pueden ser: No y No. Sin embargo, puedes negociar, visualizar y planear el crecimiento de tu sistema.

¿Aceptan pagos a meses sin intereses?

La forma más sana (como hasta en la vida misma) de atender las deudas que uno tiene es tener visibilidad de las mismas. Dentro de la industria del software la situación es (o se recomienda que sea) la misma. Para poder llevar un rastreo más eficaz de la deuda técnica se recomiendan los siguientes puntos:

Mantener un registro de las funcionalidades que generaron nueva deuda (código duplicado, falta de pruebas, diseño acoplado a un componente en específico, problemas de seguridad, etc)
Clasificar de forma quincenal (por medio del refinamiento, en caso de usar el framework Scrum) la urgencia, impacto y tiempo de cada tarea de deuda técnica
Asignar de ser posible del 20 al 25 % de la velocidad del equipo a pagar la deuda técnica que más dolencias les trae para avanzar de una forma más eficiente
En caso de ser posible, alinear las nuevas funcionalidades para que la nueva arquitectura sea más mantenible, contando con alta cohesión y bajo acoplamiento
Volver a negociar la deuda en caso de ser posible

Existen muchas técnicas para el manejo y mantenimiento de código legado, a continuación se listan algunas (de las muchas) existentes:

Faking Collaborators
Wrap Methods/Classes
Breaking Dependencies
Database Refactoring techniques
Dependency breaking techniques (Extract interface, Parametrize constructor/method, encapsulate global dependencies, etc)
Replacing conditionals with Polymorphism
Remove Middle Man
Improving via design patterns
etc

Muchas otras técnicas existen para poder lidiar con código legado o refactoring, algunas de estas las podemos encontrar en el libro de Refactoring: Improving the design of existing code, Working Effectively with Legacy Code, Effective Java y Refactoring Databases: Evolutionary Database Design, por mencionar algunas fuentes.

Estas técnicas (o métodos) pueden formar parte de nuestro set de trucos de magia para poder resolver problemas, sin embargo, habrá veces que tendremos que reemplazar bloques completos, haciendo lo posible por mantener estable el contrato de nuestra API pública.

Un caso de estudio: El equipo de tooling en Kueski

Sin entrar en detalles, en Kueski contamos con un equipo enfocado a la creación de herramientas e infraestructura para hacer más fácil la vida a los desarrolladores/ingenieros y así puedan entregar valor al negocio, considerando calidad y velocidad. Cuestiones de CI/CD, aprovisionamiento de servidores, regresiones automatizadas, infraestructura, DevSecOps, manejo de licencias, son algunos de los puntos con los que nos toca lidiar.

Desde la creación de este equipo (a la par de la implementación de la cultura DevOps) hemos empujado el financiamiento sano de la deuda técnica. Siendo un equipo de cinco ingenieros, hemos logrado dar soporte a más de 150 pipelines, incluyendo lo antes mencionado hasta la fase de entrega; ~70 integrantes del equipo de ingeniería (incluyendonos). Y por mucho podemos decir de forma muy humilde ... Sí, tenemos deuda técnica ...

Nadie del equipo era (aún no lo somos) experto en ésta área, comenzamos a notar el incremento en tiempo (o puntos del sprint) para cambios pequeños y eso nos levantó un foco rojo. Desde Agosto del 2019, comenzamos a llevar el tracking puntual de bugs/technical debt que ibamos encontrando o eran reportados por nuestros usuarios finales.

Hemos adoptado una forma de trabajo que consiste en los siguientes procesos:

Trunk based development
Feature flags
System monitoring and alerting via Slack
Service Desk (para peticiones externas o soporte a ingeniería)
Scrum (para planeación y manejo de nuevos features)
Kanban board (registro de deuda técnica)
Pair programming
- Temas de soporte
- Diseño y arquitectura de nuevos features
- Refactoring de deuda técnica
Behavior Driven Development (70 - 80% de Coverage)
Cuestiona, siempre cuestiona
Documentar la api pública
Si se rompe algo, no te preocupes, es simplemente que lo debemos mejorar
El pipeline es mi pastor, y nada me faltará
Be aware of your team
Be clear and concise

Cada qué detectamos que necesitamos seguir algún camino poco mantenible o tomar algún atajo para resolver una incidencia, reportamos el ticket de deuda técnica en el Kanban board con el siguiente formato:

Nombre del proyecto
Descripción de la deuda a pagar
Propuesta o arquitectura de solución (opcional)
Esfuerzo estimado inicial (low, medium, high, coffee time)
Esfuerzo después de terminada
Comentarios extra de la tarea

Las tareas son refinadas por la persona que la reporta (a veces éstas salen a través de una sesión de pair programming, por ejemplo); agregando diagramas o bien, bosquejos de la solución. Cada dos semanas (lo que dura un sprint), dedicamos el 20% de la fuerza (de ser posible) para atacar la deuda técnica generada, esto con la finalidad de contar con una base lo suficientemente mantenible para seguir avanzando.

Elegimos las tareas de deuda técnica que se encuentran relacionadas a un componente que requiere una mejora o bien, una funcionalidad nueva. Todo esto lo hacemos adoptando feature flags y monitoreo (con alertas en Slack), lo cual nos ha permitido actuar de forma proactiva en lugar de esperar a que nos llegue la petición por medio de un ticket o una incidencia.

Regularmente fomentamos la solución compartida a través de pair programming. Sin dudarlo hemos aprendido (o mejor dicho, re-aprendido) que varias mentes piensan mejor que una. También decidimos no contar con un coverage del 100%, ya que ante todo, nos gusta contar con cierta flexibilidad para poder innovar sin tener que lidiar con un monolito de pruebas. Hay una plática muy buena sobre ésto.

Finalmente: Salir del buró de crédito

El pago de deuda técnica es algo que se tendrá que hacer y es parte de nuestro rol como ingenieros. Es parte de un desarrollo integral el saber tratar con sistemas con deuda y legados (suelen ir relacionados pero no son dependientes), ya que no siempre podremos crear todo desde cero.

Ante todo, sé empático con el equipo y el sistema actual, el objetivo es aprender e incrementar la funcionalidad, no sólo juzgar la situación.

Sé humilde y juega en equipo, a veces nosotros mismos generamos esa deuda técnica (sí, no somos para nada perfectos), trabaja a la par con el equipo actual o equipos involucrados, para ellos es importante contar con la visibilidad y comprender el estado del arte en ese momento, así se logrará atacar de mejor forma la deuda, no sólo con un contexto sesgado.

Una gran ventaja de tener todo nuestro sistema en un estado sano y mantenible, es que cuando llegan los famosos volantazos, muy comunes en nuestra área, nos es más fácil reaccionar y adecuarnos, en lugar de tener que reinventar todo desde cero.

La frase de "Move fast and break things" tiene muchos matices, no debemos ser radicales y por ello buscar lo perfecto o bien romper todo por el bien común. Tratemos de buscar el punto medio donde probablemente algunas cosas se lleguen a romper, sin embargo, tratando de mantener al mismo tiempo toda la maquinaria funcionando ahora y pensando en un futuro.

En Tooling fomentamos la discusión, siempre apoyando los puntos de vista y empujando que exista una mejora contínua.

Aprender a lidiar con sistemas legados y deuda técnica no te hace más o menos ingeniero (a veces queremos abusar de estar siempre a la vanguardia), recuerda que todo lo nuevo en unos años, será nuevamente código legado.

Referencias

Site Reliability Engineering: Afrontando el riesgo y los desastres

Juan A. Reséndiz — Mon, 01 Jun 2020 19:36:06 +0000

"Conflict isn't an inevitable part of offering a software service" - Google Site Reliability Engineering.

¿Qué es Site Reliability Engineering?

Dentro del área del desarrollo de software, es parte de nuestro día a día resolver problemas de cualquier tipo, incluyendo el conciliar una entrega de alguna funcionalidad, la reparación de algún defecto o mejora al sistema actual.

Site Reliability Engineering, es un concepto que Google ha hecho famoso desde hace varios años, cuyo principal objetivo es unificar la parte de diseño de software con la parte operativa de un producto/servicio, tomando en cuenta factores cómo la resiliencia, seguridad, entrega, manejo de riesgos del ciclo del desarrollo de un sistema informático entre otros.

Los equipos de SRE se encuentran enfocados a procesos de ingeniería y entrega de valor al producto. Sin un proceso constante de análisis, diseño e implementación, la carga operativa suele incrementar y eso implica la necesidad de contar con más personal para ejecutar la carga de trabajo.

Uno de los enfoques principales de SRE, es reducir esa carga operacional manteniendo una razón, ah doc a las necesidades del producto sin comprometer la calidad del mismo (la propuesta de Google es 50%/50%).

Es decir, mantener la carga operativa y el proceso de innovación/automatización de forma que los equipos de trabajo no sólo se enfoquen en atender problemas operacionales, sino también realizar mejoras, resolver deuda técnica, e innovar sobre el producto en cuestión.

En esta serie de 3 publicaciones, estaremos hablando de temas relacionados a SRE y cómo estos conceptos nos pueden ayudar a mejorar nuestro ritmo de trabajo, trabajando a la par con las áreas involucradas para que nuestros sistemas cumplan con los requisitos de calidad, disponibilidad y seguridad propuestos por el equipo o la competencia en sí.

Disponibilidad: Manejando el riesgo y los desastres en el software

Todos los sistemas son propensos a fallos. Si un sistema aparenta no tener fallos, es probable que los tenga, simplemente aún no se han presentado.

Cuando existe algún tipo de fallo o riesgo en algún sistema, éste desgasta la relación con los usuarios (sean internos o externos); uno de los objetivos de SRE es fomentar la reducción o acotación de éste riesgo.

Existen varios factores que determinan el costo de los factores de disponibilidad, los dos principales son:

Redundancia: Ya sea en equipo físico, recurso humano o espacio para lograr ejecutar un plan de acción ante un fallo (o responder ante alguna anomalía).
Costo de oportunidad: Los recursos que una organización desea considerar para el diseño de funcionalidades minimizando el riesgo. Estos recursos no sólo se enfocan a la disponibilidad/seguridad; si no también pueden representar nuevas funcionalidades o mejoras al sistema/producto.

Es importante mencionar que no todos los recursos deben ser enfocados a la disponibilidad, ni tampoco al desarrollo de nuevas funcionalidades; ya que este balance puede ir cambiando con el paso del tiempo.

Factores como el diseño del sistema, el cliente final, criticidad del servicio, cantidad de deuda técnica, por mencionar algunos, son pilares a considerar para definir cuál debe ser la disponibilidad de un servicio.

La mejor forma de poder tomar una decisión es teniendo métricas dentro de los sistemas, sin embargo, si tomamos un sistema nuevo, se puede conciliar contar con algún tipo de holgura y conforme pasa el tiempo (un trimestre, por ejemplo) determinar el peso de cada uno de los factores y así mejorar la propuesta.

Dentro del libro de SRE, se mencionan las siguientes dos propuestas de medición de disponibilidad de un sistema:

Usualmente la disponibilidad es calculada por el número de 9s que el proveedor del servicio puede garantizar. Una disponibilidad de 99.9% habla de un porcentaje de baja disponibilidad de apróximadamente 8.76 horas al año. Cada número nueve agregado a ese valor, implica un análisis profundo de la arquitectura actual, infraestructura y costos: en horas hombre, contratos con proveedores y mantenimiento.

Para poder afrontar el riesgo dentro de nuestros sistemas es necesario tomar en cuenta las siguientes preguntas:

Disponibilidad
- ¿Cuál es el nivel requerido de disponibilidad?
- ¿Cómo es el manejo de las integraciones con terceros en caso de que éstas fallen?
- ¿Cómo podemos aprovechar el costo de oportunidad para ayudar a reducir los riesgos?
Negocio
- ¿Cuál es el nivel de disponibilidad que provee la competencia?
- ¿El servicio impacta directamente en las ganancias (del producto o servicio)?
- ¿El servicio es gratuito o de paga? (Considerando un SLA)
- ¿Actualmente cuál es el proceso de control de calidad con el que se cuenta? (El balance en la pirámide de pruebas)
Diseño y Arquitectura
- ¿Las métricas actuales fueron diseñadas considerando la deuda técnica?
- ¿Cuál es la frecuencia de actualización del servicio? ¿Se intenta encontrar un nicho en el mercado o es un servicio ya establecido?
- ¿Cómo es el proceso de monitoreo actual? (Logs, red, consultas, tiempos de respuesta, consumo de memoria, etc).
- ¿Es necesario contar con algún requisito de seguridad? ¿El servicio se encuentra dentro de una Trusted Computer Base (TBC)?

Estas preguntas pueden formar parte del diseño y creación de cualquier sistema que desee contar con alta disponibilidad, y ser consideradas no sólo a nivel sistema, también a nivel funcionalidad y adecuarse a cómo sea necesario.

Siempre existe la alternativa de contar con distintos niveles de disponibilidad dependiendo el servicio, con base en la cantidad de subscriptores/funcionalidades, así los clientes pueden elegir el plan que más les convenga (cambiando los beneficios y el esquema de cobro).

Trabajando para ser seguros y resilientes

Un sistema que sólo se encuentra orientado a cuestiones de seguridad y resiliencia, sin contemplar los requerimientos de funcionalidad de negocio, tiende a ser un sistema rígido y poco usable. Es importante tener en cuenta lo antes mencionado para conciliar estos requerimientos y saber que siempre existirá un riesgo que debemos considerar como aceptable para no dificultar el flujo de trabajo.

Durante la creación de un proyecto, la etapa de toma de requerimientos y diseño es indispensable para poder delimitar las fronteras del sistema, es decir, el acoplamiento con otros módulos, bases de datos, bibliotecas, sistemas de archivos, interfaces de red y servicios externos.

Existen patrones de diseño y de arquitectura que pueden ayudar a disminuir el riesgo de acoplamiento con algún sistema o biblioteca; sin embargo, el riesgo siempre estará ahí y no por estar aislado dejará de existir.

Dentro del flujo de trabajo de cualquier equipo, es indispensable contar con ciertas etapas durante el desarrollo para garantizar la integridad y calidad del producto que entregamos. A continuación se mencionan algunas fases a considerar:

Análisis de dependencias
Análisis de licencias
Análisis de vulnerabilidades
Cobertura de código
Code smells/Linting
Pruebas unitarias, de integración, de sistema

Estas fases son algunas que pueden ser tomadas como parte de cualquier flujo de trabajo, siempre de forma automatizada por medio de algún servicio de integración continua como Jenkins, CircleCI, TravisCI, Github Actions, etc. Estas fases de desarrollo pueden fungir como un integrante más al equipo de trabajo; un integrante imparcial con una visión y procesos automatizados.

El contar con procesos automátizados y replicables, es parte de la cultura Devops. Debemos ver éste proceso de automatización como una inversión a largo plazo para mejorar la calidad, más allá de un bloqueante durante las etapas tempranas del desarrollo.

Tocando temas de seguridad, al igual que al hablar de temas de resiliencia, entre más seguro sea un sistema, tiende a ser menos usable, ya que cada capa de seguridad puede llegar a entorpecer la usabilidad y tiempos de respuesta de un servicio; y entre más componentes llegue a tener un sistema, mayor es su superficie de ataque.

Muchos de los factores de seguridad y disponibilidad suelen ser no tangibles y en general abstractos respecto a temas de negocio, por lo mismo no son tomados como prioridad durante las fases de desarrollo; también suelen ser emergentes conforme pasa el tiempo.

A nivel seguridad, esta puede ser una lista de referencia de factores a tomar en cuenta:

¿Cómo el servicio se encuentra estructurado (módulos, monolito, microservicios)?
¿Cuáles son los mecanismos de comunicación entre servicios (REST, RPC, Sockets)?
¿Cómo se encuentran estructuradas las pruebas para realizar validaciones de seguridad o sanitización?
¿Se debe contar con algún tipo de restricción por cuestiones de legislación o manejo de datos? ¿Qué información con la que tratamos debe ser cifrada o sanitizada?
¿Cuáles son las técnicas de autenticación mínimas requeridas para garantizar la auditabilidad de accesos?
¿Se cuenta actualmente con un proceso de aplicación de parches de seguridad en el sistema actual?
¿El sistema cuenta con los roles necesarios para garantizar el principio del menor privilegio?
¿Dentro del diseño se consideró contar con CIA (Confidentiality, Integrity, Availability)?

Una estrategia que puede ayudar al SRE, Product Owners y equipos de ingeniería en general, es seguir un template de requerimiento/diseño con las preguntas que se consideran relevantes, por ejemplo:

Feature #1

Description:
    A description about the feature.

External/Internal Dependencies:
    A list of all the possible dependencies that might be used by the system itself
    and how they will be managed.

SLA:
    Service Level Agreements that needs to be achieved for this feature.
    If they don't exists; at least SLO should be managed for the service

Security and Data considerations:
    If there is any consideration about how the service's data has to be handled
    (obfuscating or anonymizing data). This point it's suitable to describe the
    minimum security levels for the feature/system, at least the service
    should live in a TCB. If the managed data needs to be encrypted, this needs
    to be handled here, like the used algorithm or provider.

Do the service creates new technical debt?
    It's important to keep in track all the technical debt created/paid by the team,
    so it doesn't overwhelm the deliver velocity.

Service/Feature technical requirements:
    Database versions, languages, dependencies, coverage levels.

Architecture diagrams:
    If required, the service diagrams are suitable for a quick review.

Como punto indispensable, se recomienda que todos los sistemas diseñados puedan contar con un proceso de auditabilidad, con la finalidad de poder afrontar las incidencias que puedan llegar a presentarse; brindando la visibilidad y permisos mínimos para resolver el problema.

El manejo de logs es una parte indispensable para el monitoreo de un sistema, y no sólo es contar con éstos, también que deben proveer información importante sobre los procesos que un sistema ejecuta, sin exponer información sensible sobre clientes, por ejemplo.

Existen muchas alternativas para manejar el monitoreo dentro de tus aplicaciones, servicios como Prometheus, Datadog, ELK, AWS Cloudwatch, etc; pueden ser integrados a tu sistema. Muchos de estos servicios te permiten generar dashboards para poder realizar un análisis de lo que pasa actualmente.

La inclusión de alertas (con base en ciertos errores o umbrales de las métricas) nos permite reaccionar ante algún tipo de incidencia, ya sea de forma manual o programática; además de mantener a los equipos de trabajo en sincronía de lo que pasa en los ambientes productivos.

Dentro de las métricas que pueden formar parte de un sistema, estas son las que se recomienda mantener monitoreadas:

Uso de memoria
Logs de procesos críticos de sistema operativo (journalctl)
Logs del proceso productivo (se recomienda que sean mostrados directamente en el STDOUT, así será más fácil su integración con contenedores)
Tráfico de red
Métricas de CPU
Uso de disco

La periodicidad de recolección de las métricas, dependerá de la razón de ser del componente; por ejemplo: Imaginemos un servicio con con una interacción constante a una API externa y un proceso matemático complejo. Dado esa breve (y muy vaga) descripción, probablemente el uso de disco no sea una métrica que debamos obtener minuto a minuto, sin embargo, el uso de CPU y el tráfico de red se convierten en válidas opciones para tener con una mayor frecuencia.

Todo explotó: Un plan ante el desastre (Disaster Recovery Plan)

Por más intentos materiales y humanos invertidos en cualquier proceso de ingeniería, estos tendrán defectos y existirán errores; cómo SREs, es nuestra misión inculcar una cultura orientada a evitar desastres, al mismo tiempo contar con planes de contingencia para mitigar posibles errores humanos, ventanas de mantenimiento, incidentes de seguridad, etc.

Un DRP (Disaster Recovery Plan) consta del conjunto de procedimientos, acciones y puntos de contacto mínimos para mantener el negocio funcional mientras se trabaja en recuperar el estado más reciente del sistema.

Este tipo de plan se debe realizar a la par con todas las áreas de negocio, no sólo desde ingeniería; para poder garantizar la mayor cobertura operativa en caso de algún incidente. Los DRP se deben encontrar actualizados y adecuados al giro actual de la empresa.

Dentro del desarrollo de un plan de recuperación, existen algunos conceptos base que deben ser tomados en cuenta:

RTO: Recovery Time Objective. Se define como el tiempo que necesita la empresa para poner sus sistemas nuevamente en línea y funcionales después de que un evento fue declarado.
DT: Decision Time. Muchos lo consideran el tiempo más crítico dentro de un plan de contingencia; este es el tiempo involucrado desde que se conoce la incidencia hasta que se inicia con el plan de recuperación. Este tiempo es crucial, ya que depende de los managers, leads, CTO, SREs el tomar la elección de ejecutar. A veces el tiempo invertido en soluciones por parte del equipo de ingeniería puede verse reflejado en minutos u horas con pérdidas de información. No existe una fórmula perfecta para esta métrica y depende de la criticidad del incidente, servicios afectados, horas del día o las personas involucradas.
RPO: Recovery Point Objective. Es el tiempo entre tu último respaldo y cuándo se decidió ejecutar el plan de recuperación. Estos respaldos se pueden dejar en otras cuentas o medios físicos, de cualquier forma, es importante recordar que la consistencia de la información es la más importante.
WRT: Working Recovery Time. Es el tiempo estimado en ejecutar el plan de recuperación desde que inicia hasta que éste mismo es culminado. Este tiempo puede ser tan crítico como la información involucrada en el sistema mismo.
MTD: Maximum Tolerable Downtime. El tiempo máximo permitido en el que los sistemas pueden estar como no disponibles, es decir, el tiempo que la empresa puede tolerar no contar con un sistema funcional.

El DRP debe estar documentado y ser conocido por todas las áreas involucradas, además de contar con un proceso de revisión (dependiendo el servicio y la tasa de cambio del mismo) que puede ir de un trimestre, hasta un par de años.

Conclusión

SRE es un tema integral dentro del desarrollo de una aplicación o sistema, forma parte integral de los procesos operativos y de ingeniería. Es importante tener en cuenta que no existe una fórmula para solucionar todos nuestros problemas de riesgo y disponibilidad, la baraja de opciones es infinita, agregando también la gran velocidad con la que la industria de software suele moverse.

Sin embargo, este tipo de cuestionamientos y lineamientos son algo que no ha cambiado a lo largo de los años en la industria del software. Deben ser considerados como guías para un trabajo contínuo y de calidad, más allá de normas por seguir.

Los desastres siempre ocurrirán, sea cual sea su magnitud. SRE fomenta una cultura para afrontar este tipo de retos de forma ordenada, segura y eficiente; sin dejar detrás la importancia que tiene el negocio y los clientes en el proceso.

La flexibilidad y la aceptación de éstos horizontes desconocidos nos permiten siempre tener un campo fértil para la innovación, siempre y cuando se tenga un diseño flexible y estructurado de lo que deseamos alcanzar.