Orán en estado salvaje y lo que nos sorprendió

Una nota de la versión describe lo que hace una versión. Es menos común describir lo que pasó después, en parte porque la respuesta suele ser ligeramente embarazosa.

Aquí hay tres cosas en las que nos equivocamos.

Esperábamos que la atribución de costos se utilizara para calcular los costos.

Orán atribuyó 3,1 gastos por agente porque los equipos no pudieron responder cuánto costaba nada. Eso fue correcto y el uso no fue el que esperábamos.

Lo primero que hicieron la mayoría de los equipos con la atribución por agente fue no reducir el gasto. Fue encontrar agentes que nadie sabía que estaban huyendo. La atribución resultó ser una herramienta de inventario antes de ser financiera, porque una línea de costos sin un propietario reconocido es la señal más clara posible de que algo se ha olvidado.

Esto reformuló nuestra forma de pensar sobre la propiedad, y es en gran parte la razón por la que 3.6 trata la propiedad como una propiedad de un agente y no como una convención.

Esperábamos que los presupuestos se fijaran generosamente

Creamos presupuestos para disyuntores en 3.2 asumiendo que los equipos establecerían un límite muy por encima del uso esperado, como red de seguridad contra el comportamiento descontrolado.

Muchos los colocaron deliberadamente ajustados, cerca del uso esperado, y utilizaron el bloqueo como una señal en lugar de una protección. Cuando un agente alcanzó su límite, eso fue información: algo cambió, mírelo.

Habíamos construido una barandilla y los equipos la estaban usando como detector de humo. Funciona y no es para qué sirve la función.

Esperábamos que las evaluaciones se escribieran antes de la implementación.

Orán 3.3 supuso que los criterios se definirían de antemano, que es lo que recomendaríamos y lo que casi nadie hace.

En la práctica, la mayoría de los equipos escribieron su primera evaluación después de que un agente produjo algo incorrecto, trabajando hacia atrás desde el error. Los criterios resultantes fueron más limitados que un conjunto diseñado y con frecuencia más útiles, porque codificaban un fracaso real en lugar de uno imaginario.

Dejamos de tratar esto como si los equipos lo hicieran incorrectamente. Un conjunto que crece a partir de fracasos reales converge en algo bueno y tiene la ventaja de existir.

¿Qué aguantó?

La asimetría lectura-escritura. Los equipos otorgan a los agentes un amplio acceso de lectura y un acceso restringido de escritura, de manera consistente, en todos los sectores en los que trabajamos. Construir la capa de políticas en torno a esa suposición fue correcto.

El valor de un catálogo compartido. La duplicación entre equipos fue tan grande como esperábamos y Agent Hub la abordó como se esperaba, que es el elemento menos sorprendente de esta lista.

Por qué publicamos los fallos

Porque una plataforma construida únicamente sobre lo que sus creadores esperaban se aleja de lo que hacen sus usuarios. Cada una de las tres sorpresas anteriores cambió algo en 3.6, y ninguna de ellas habría surgido de una hoja de ruta.

Si su despliegue está haciendo algo con Orán para lo cual claramente no lo diseñamos, nos gustaría saberlo. Eso es realmente lo más útil que recibimos.

Siguiente

La página de versiones cubre todas las versiones desde Keter 1.0 en adelante. Unirse a la Comunidad de Desarrollo Abierto es gratuito y las observaciones pueden enviarse a contact@capconsultor.eu.