Estuve haciendo bastante SRE (Systems Reliability Engineering), para Libres en estos días (y voy a seguir haciéndolo en próximas iteraciones del ciclo de mejora contínua), pero muy poco de llevar esas nociones a código y configuraciones (vamos a volver a hacer eso hoy). Sin embargo es tiempo bien invertido.
Ingeniería de confiabilidad - RE - Reliability Engineering
Acá está la página de la Wikipedia para el tema en gral.
Links
Y dejo algunos links acá mismo, RE es un campo de trabajo muy requerido en el extranjero, no tanto en Argentina en gral.:
"What's the role of the reliability engineer?"
Site Reliability Engineers: “solving the most interesting problems”
Al 05/09/2013 tenemos: 972 results for Senior Reliability Engineer jobs
Fijénse por ejemplo, lo que es la definición de búsqueda para un RE:
"..currently seeking a Reliability Engineer with a strong understanding of the fundamentals of Reliability Engineering, extensive experience/exposure in one or more engineering disciplines (mechanical design, electrical circuit design), and the mindset & desire to drive product development culture change and lead global Reliability Engineering/Design for Reliability initiatives."
Mi Plan
Bueno, como ven me focalicé en el plan de RE, a ver..
Fijénse estos párrafos, es el por qué un plan de SRE es necesario:
"A reliability program plan is essential for achieving high levels of reliability, testability, maintainability and the resulting system"
y
"A reliability program plan is used to document exactly what "best practices" (tasks, methods, tools, analyses and tests) are required for a particular (sub)system, as well as clarify customer requirements for reliability assessment"
Básicamente armás un marco dentro del cual tu sistema/s van a funcionar, pero bien, y el - método/procedimiento/s de - cómo vas a lograr mantenerlo funcionando así de bien.
La idea general es básica, por ejemplo, si vas a construir un puente, no solo construís el puente, sino tenés que pensar en cómo se va a mantener bien pintado, en condiciones óptimas luego de terminado. Allí vas a ver que hace falta interconstruir determinadas cosas en el puente: desde escaleras para los que van a auditar/mantener el puente, hasta ver los materiales y componentes que son reemplazables en diferentes etapas del ciclo de vida, y qué tan accesibles son para la gente a cargo del mantenimiento (si se consiguen, pueden comprar dentro de un radio de 100 a 1000 km. del puente, o dentro de un radio de 10.000 a 20.000 km), es una variable a considerar para elegir materiales y componentes a utilizar, siempre que todos cumplan los parámetros mínimos requeridos para su función, etc.etc.
Acá lo podés leer mejor:
"Availability and is developed early during system development and refined over the systems life-cycle."
y está bien definido qué es Disponibilidad:
Así también, usando el principio KISS, manteniendo todo simple, logramos evitar este inconveniente:
"In general, the amount of work required for an effective program for complex systems is large."
Lo que sigue, se refiere a lo que la filosofía Devops y sus filosofías de ingeniería asociadas plantean en gral: es mejor mantener un buen MTTR para el sistema que focalizarse totalmente minimizar los MTTF del sistema.
"A Reliability Program Plan may also be used to evaluate and improve Availability of a system by the strategy on focusing on increasing testability & maintainability and not on reliability. Improving maintainability is generally easier than reliability. "
Llegar a entender bien el párrafo siguiente es lo que permite diseñar productos y servicios perfectamente alineados con los recursos disponibles y con el escenario / mercado objetivo donde van a funcionar:
"Maintainability estimates (Repair rates) are also generally more accurate. However, because the uncertainties in the reliability estimates...
...Testability of a system should also be addressed in the plan as this is the link between reliability and maintainability. The maintenance strategy can influence the reliability of a system (e.g. by preventive and/or predictive maintenance), although it can never bring it above the inherent reliability."
Listo, y la conclusión:
"The Reliability plan should clearly provide a strategy for availability control. Whether only Availability or also Cost of Ownership is more important depends on the use of the system."
Hay mucho más claro y faltan nociones adicionales y detalles prácticos importantes en los comentarios de arriba, así que como mínimo para hacer una introducción completa al tema, recomiendo leer la página completa sobre reliability engineering de la Wikipedia.
No hay comentarios:
Publicar un comentario