El factor tiempo (la puntualidad de la ejecución de las órdenes, el trabajo, los acuerdos) es importante en los negocios. Los clientes y socios esperan una colaboración predecible que requiere mucho tiempo. En un negocio tradicional, esto está influenciado por el trabajo de los empleados, las acciones de los proveedores, la ubicación geográfica de la empresa, la condición del equipo y mucho más. Localizar y controlar todo esto es una tarea difícil.
Un poco más claro, todo está en el campo de TI. Una parte importante de los procesos puede automatizarse y confiarse a un programa o script. Aún mejor, si el producto se implementa como un servicio web, la lección principal es apoyar la disponibilidad y el desarrollo del producto.
Uno de los principales productos de nuestra empresa es un servicio web. Todo comenzó con la implementación de la idea de dos personas, luego la compañía creció: PM (él también es un programador web), un programador de bases de datos, un administrador de sistemas (con poca experiencia de desarrollador), un probador y otras dos personas involucradas en ventas y SEO. El sistema se implementa como una interfaz web y una base de datos relacionada. El uso del servicio implica depositar y retirar dinero almacenado en una "moneda virtual". Por seguridad, el servidor web y la base de datos se implementan en sus servidores.
Dado que el servicio está conectado con dinero, el nivel de confianza del usuario en el sistema es importante. En primer lugar, es una cuestión de seguridad y de proteger el sistema contra piratería. Sin embargo, es difícil para un cliente común (especialmente no versado en las complejidades de TI, protocolos seguros y encriptación) evaluar el nivel de seguridad del sistema. Si no se ha producido una situación negativa (piratería), el trabajo no es visible.
La accesibilidad del sistema es más obvia para el cliente: si el usuario transfirió una cierta cantidad a la cuenta virtual y luego no puede iniciar sesión en el sitio varias veces, la credibilidad del sistema se debilita y el cliente probablemente se pierde (a veces varios a la vez, lo negativo se propaga rápidamente). Y tampoco es probable que los usuarios involucrados con gran dificultad, que se encuentran con un error en lugar de la página principal del sitio, regresen.
Comprender la seriedad de esto no vino de inmediato. Al principio, el número de usuarios era pequeño, las capacidades del servidor y del canal eran abundantes y, por lo tanto, los "bloqueos" eran raros. Además, al principio, la funcionalidad a menudo se probó y refinó en aras de la optimización, y el propio desarrollador fue responsable de monitorear los servidores asociados con el servicio durante las horas de trabajo. El número de usuarios durante las horas libres fue relativamente pequeño: los clientes de otras zonas horarias estaban prácticamente ausentes en ese momento.
Poco a poco, la parte principal del servicio se completó. Las mejoras se hicieron pequeñas y, por lo tanto, la atención principal de los desarrolladores se cambió a otro proyecto. La responsabilidad del control del sistema se delegó al administrador del sistema, además de sus otras responsabilidades. Se enviaron notificaciones por correo electrónico y SMS al administrador en caso de un bloqueo del servidor. Tales medidas en ese momento parecían suficientes.
El producto comenzó a ganar impulso y la cantidad de usuarios aumentó. Surgieron nuevas ideas, algunas se implementaron de inmediato, otras se pospusieron para el futuro. El servicio fue traducido a otros idiomas y gradualmente ingresó a nuevos mercados, lo que, entre otras cosas, condujo a un aumento en el número de usuarios por la noche. La carga del servidor estaba creciendo gradualmente, aunque todavía estaba lejos del límite técnico del hierro.
Una vez que la calma llegó a su fin. En la noche del viernes al sábado, los usuarios comenzaron a experimentar problemas para acceder a la página principal del sitio, a menudo se encontraron con el error 503. El problema era simple, pero, como debería ser, el administrador no estaba disponible el viernes por la noche y, por lo tanto, el SMS permaneció sin leer. Sin embargo, el problema se resolvió de manera relativamente indolora. El desarrollador también recibió un SMS, pudo comunicarse y despertar al administrador, y después de 3 horas se resolvió el problema. El "tiempo de inactividad" total fue de 5 horas.
El lunes, hubo un informe de lo que sucedió. El análisis de los datos de tráfico del sitio mostró una imagen desagradable: en un viernes "problemático", el tráfico disminuyó en un tercio en comparación con el año pasado, pero las caídas significativas el sábado y el domingo fueron aún más desagradables, a pesar de la ausencia de problemas técnicos en estos días, el tráfico se redujo en un 15%.
Esto reforzó la comprensión de la necesidad de un monitoreo continuo. Desde el punto de vista del software, elegimos
Zabbix , que debía ser instalado y configurado por el administrador del sistema. Tomó alrededor de una semana: el resto de las tareas no fueron a ninguna parte, y todo se hizo en paralelo. Hubo una pregunta organizativa: ¿quién supervisará exactamente?
Al principio, tuve que tomar esa decisión: cambiar las horas de trabajo de los empleados existentes (de aquellos que entendieron esto, es decir, el administrador del sistema y el desarrollador) para que uno por uno alguien controlara el servidor por la noche.
Esta fue una decisión forzada y no duró mucho. En primer lugar, el trabajo de dos personas todavía no proporciona control las 24 horas; hay brechas en el tiempo en las que también es probable un fallo. En segundo lugar, a pocas personas les gusta trabajar de noche, y la insatisfacción creció, además, la distracción del programador casi detuvo el desarrollo en sí. Por lo tanto, después de una semana abandonaron la idea y comenzaron a pensar más.
Contratación de personal adicional para monitorearPor supuesto, tal decisión es la más intransigente: el control constante de las personas seleccionadas da un buen resultado. Pero trabajar en este modo requeriría una búsqueda de 3 administradores de sistema más. Además, deberían estar lo suficientemente calificados para resolver problemas, pero la mayor parte de su tiempo se desperdiciaría de todos modos: la empresa es pequeña, hay pocos servidores y no habría casi nada para ocuparlos. Además, muchas personas también necesitan ser controladas, lo que sería un dolor de cabeza adicional.
Ambas opciones no funcionaron. No fue posible concentrar esfuerzos y medios en ellos. Pero la necesidad de monitoreo no ha desaparecido. Este es uno de los problemas del crecimiento: existe una necesidad que no podemos realizar por nuestra cuenta. Como solución, llegamos a una subcontratación.
Durante la transición, surgieron dudas, la principal fue la seguridad y confidencialidad de la información que está disponible para otra persona y la calidad del servicio, ¿no empeorará, por el contrario? Pero es más bien una cuestión de encontrar un ejecutor responsable y firmar un NDA.
Entonces, seguimos adelante, desde el punto de vista técnico no fue difícil. Un mes después, decidimos verificar cómo iban las cosas, verificando los registros en los servidores. Estamos satisfechos con los resultados: durante el mes hubo tres fallas graves que podrían "poner" el servidor nuevamente, pero los socios resolvieron los problemas en media hora. Además, todas las fallas ocurrieron en el intervalo de la una de la mañana a las cuatro de la mañana, un crecimiento geográfico gradual del producto afectado.
El trabajo de nuestro administrador del sistema ha cambiado y se ha vuelto más relajado. Sin distraerse con el monitoreo, se concentró en DevOps. Centramos nuestros esfuerzos y el desarrollo se aceleró. Resultó darse cuenta de lo que se pospuso durante mucho tiempo, gracias a nuestro
socio .