Trabajo en el departamento de sistemas informáticos de CROC, apoyamos todo lo que se pueda tirar al muro. Es decir, servidores, sistemas de almacenamiento de datos y otro hardware costoso en los centros de datos. Bueno, el hecho de que tenga sistemas operativos, infraestructura básica. El servicio básico más simple son los repuestos, es decir, la sustitución de componentes a tiempo. Los más complejos están reemplazando a los administradores de sistemas del cliente.
El momento más aterrador del contrato es la redacción de los términos de referencia. Te contaré sobre el rastrillo que sentimos junto con los clientes y cómo evitarlos. Bueno, adjuntaré un ejemplo de la plantilla TK que usamos.
Aumentar las estadísticas
La primera jamba de todas las especificaciones técnicas es una ignorancia banal del número promedio mensual de aplicaciones. Se ve así: desea subcontratar la administración, luego debe comprender cuánto costará. Si solo adjunta una descripción del parque de equipos, entonces nosotros, como participante en la competencia, estimaremos el enchufe por la cantidad de trabajo, visitas, si es necesario, y lo entregaremos con cierto margen. Pero si sabe exactamente cuántos y qué boletos hubo el año pasado, entonces el precio puede bajar drásticamente; después de todo, puede ver de hecho qué y cómo se descompone y con qué frecuencia se realizan cambios en la infraestructura. Alguien, por ejemplo, agrega máquinas virtuales todos los días, y alguien una vez al año; el precio será el mismo en la primera aproximación.
A menudo, la tarea del cliente parece "Ahora adminístrelo todo por nosotros". ¿Y qué es eso? El proveedor del servicio (es decir, para nosotros) no comprende el volumen, todo se vuelve a hipotecar por los costos laborales. Si redimimos, pagará de más. Si de repente el precio sube en el transcurso del contrato, habrá conflictos. Si de repente sucede algo y aceptamos un contrato más barato de lo que realmente cuesta, intentaremos rechazarlo y al final tendremos que buscar un contratista nuevamente.
A veces sucede que el cliente no conoce su infraestructura en absoluto (por ejemplo, después de una fusión o adquisición o la salida repentina del administrador anterior). Y solo si es una rama, y no han mirado allí durante mucho tiempo. En este caso, debe realizar la auditoría desde el principio. La auditoría, por supuesto, cuesta dinero en sí misma, pero ahorra mucho dinero en el contrato posterior. Y los resultados de la auditoría se pueden mostrar en una competencia si desea comparar proveedores a un precio por unidad de servicio. Después de todo, pensamos cómo: hay un precio de trabajo (reparación, salida), hay una comprensión de cuántos y qué dispositivos. Luego miramos: habrá tantas fallas por mes para tal o cual unidad, le dedicaremos mucho tiempo. Bueno, o toma un sistema de respaldo. Aquí es suficiente que alguien configure una vez y solo verifique que se realicen todas las copias de seguridad. Y alguien cambia las políticas sin cesar, agrega, elimina,agrega de nuevo. Hemos estado administrando desde los años 90 y hemos estado recopilando estadísticas en todo momento, por lo que predecimos con bastante precisión. Y cuando "hay tantos servidores de relleno incomprensible, algunas máquinas virtuales, SO incomprensible y algo más allí, necesitas administrar, el tipo se rinde", los precios inhumanos están garantizados. Además, a menudo vienen a nosotros con equipos antiguos, para los que no ha habido apoyo del fabricante durante mucho tiempo.
El siguiente paso es dividir el contrato en trabajos regulares y raros. El caso es este: si se trata de algún tipo de trabajo permanente con una duración fija, lo seleccionamos en un bloque aparte y prescribimos regularidad. Para tareas raras, formamos una lista de sistemas de solución para los que se necesitan competencias (incluso si se necesitan una vez al año). El contratista preparará especialistas. Y no lo incluirá en la lista de precios principal. Simplemente registrará las tarifas de dichos trabajos.
Mi ejemplo favorito es cuando un cliente decidió que la administración incluye una migración completa de los servicios en los que se estaba ejecutando el sitio a otro centro de datos a una distancia de 1000 km junto con los servidores. Como, tomar los servidores y todo lo que se lleva junto con ellos (red, almacenamiento, datos en ellos ...) y tomarlo, nosotros pagamos por su administración. Pero esto es bastante fuera de lo común. Por lo general, seleccionamos estas cosas en proyectos separados y trabajamos la migración en detalle.
Tiempo de reacción
Regularmente veo clientes que prescriben tiempos de reacción incorrectamente o que no prescriben en absoluto. Es mejor arreglar todo aquí para que las expectativas coincidan con la realidad. Es muy importante escribir SLA estricto para equipos críticos: por lo general, tenemos un tiempo de respuesta de 15 minutos, reemplazo, cuatro horas. Pero si hace esto para todo el hardware en el centro de datos, el precio volverá a resultar inhumano. También hay contratos más complejos. Tenemos instalaciones de producción donde el precio promedio es más alto de lo habitual, pero al mismo tiempo nos suscribimos al hecho de que pagamos varios millones de rublos por hora de inactividad. Porque el ciclo de producción está ligado a estos nodos. Nuestro oficial de servicio no notó que la memoria estaba llena en el servidor o que se retrasó en el camino con una pieza de repuesto; es posible, al final del año, quedar en deuda con el cliente.
Por lo general, la producción, cuando quiere un trabajo único (como fallas), intenta prescribir un SLA durante 15 minutos, sin comprender qué hay detrás. Para enviar a un ingeniero con tal autorización, debe estar de servicio todo el año y no beber en Año Nuevo (o beber estrictamente de acuerdo con el ajedrez con sus colegas). Y cuesta dinero, y no como un servicio de una sola vez.
Había un contrato cuando era necesario mantener el 99% del tiempo de actividad, y lo pagaban con penalizaciones por salir del indicador. Analizamos la infraestructura, decidimos que, en principio, no sería suficiente y todo debía rehacerse. El contrato no estaba incluido, pero conocemos a los que decidieron montar. No funcionó.
Reportando
El tercer rake favorito es que el cliente no establece el formato de informe. Diseñe el formato de informes que desea ver. E indicar su frecuencia en el contrato. Si todas las tareas se realizan a sus tarifas, entonces es mejor que el contratista informe sobre la estimación preliminar de la duración del trabajo antes de comenzar a trabajar.
Esta es la pregunta "¿Por qué tienes aquí dos horas y no una y media?" Es una disputa eterna. Lo resolvemos de la siguiente manera: antes de reparar, le damos al cliente un presupuesto con un error de más o menos 10% a los lados. Ponemos grandes tareas en proyectos con un plan de trabajo y plazos de ejecución.
Está claro que se necesita control por ambos lados, lo cual es una pérdida de tiempo: dejamos entrar al cliente en nuestros sistemas y cortamos fanáticamente los informes para que no haya sorpresas. Porque estamos interesados en renovaciones por un año, dos, tres y cinco. Y sabemos que si no hay una sensación de total control y previsibilidad, tampoco habrá renovación de contrato.
También es útil programar reuniones periódicas. El primer mes de cada semana para construir el proceso, luego con menos frecuencia para que el proveedor comparta contigo las recomendaciones de lo que ve. Luego, una vez al mes, al menos una vez al trimestre. Tenemos un cliente que deja a su subcontratista en un mes y ni siquiera lo sabe. Porque no hay diálogo. No escuchan al cliente y hacen todo como hace cinco años. Es decir, sin tener en cuenta sus nuevos requisitos comerciales. El cliente estaba tratando de transmitirlo, pero luego escupió, comenzó a buscar un nuevo contratista.
Documentación
El rastro número cuatro es la virtual ausencia de documentación en el sitio. Sí, sé que a nadie le gusta hacer cambios en la documentación de la infraestructura. Si no lo escribe en el contrato, entonces hizo algo allí, rehizo algo aquí, pero se olvidó de decirlo: una situación común. La alternativa es llevar a alguien que lo mantenga actualizado por usted (cambió algo, reflexionó). Será fácil cambiar de intérprete o transferir el acompañamiento a especialistas internos.
Hemos venido cientos de veces de los documentos: solo DRP de aproximadamente 2011. Y no puedes usarlo. En mi memoria, hay al menos dos casos en los que dichos clientes tuvieron problemas de producción. Resultó que ayudaron a descubrir cuál era el problema: el DRP no funcionó porque la IP cambió.
No olvide recoger la descarga al final del período.
Los subcontratistas avanzados mantienen CMDB: instalaron nuevos equipos, los agregaron a la base. Todo se mantiene actualizado. Si no hay una base CMDB propia, las organizaciones de servicios siempre tienen una. Bueno, si no se trata del tuyo, solicita acceso. Y asegúrese de agregar una cláusula al contrato, de modo que los datos acumulados le sean transferidos en el momento de la rescisión del contrato. Tenemos un cliente que se alegró de que lo siguieran dónde qué garantía, dónde qué licencia. Pero cuando terminó el contrato, tuve que hacer un inventario urgente de todo yo mismo. Este fue nuestro primer servicio junto con una auditoría: la contraparte anterior no quería compartir los datos.
No tema incluir multas elevadas en su contrato
Un artista normal los trata bien. La voluntad de suscribirse a ellos es un indicador de que el proveedor confía en adherirse al SLA. El único punto: si transfiere directamente el control sobre la disminución de la productividad y fija el porcentaje de disponibilidad, haga, por ejemplo, un mes para un período de transición en el que no se apliquen sanciones. Se necesita un mes para profundizar en la infraestructura de TI, actualizar la documentación, obtener todos los accesos y luego garantizar la disponibilidad. Si alguien se suscribe sin él, su infraestructura estará amenazada durante el primer mes.
Por cierto, también debe medir lo que cree que es el nivel normal de rendimiento en la infraestructura viva. Entonces habrá algo con lo que comparar y mostrarle al artista que la productividad ha disminuido. De lo contrario, no lo probarás.
Involucrar inmediatamente a un especialista en seguridad de la información en el proceso de desarrollo.
Esto es tan importante que a menudo define el proyecto en general. Una vez más: involucremos inmediatamente a un especialista en seguridad de la información en el proceso de desarrollo. Si de repente no hizo esto, espere problemas. La mayoría de las veces, se administran de forma remota, por lo que el proveedor debe comprender cuáles serán los requisitos. Por ejemplo, hay clientes para quienes la videovigilancia de la estación de trabajo dedicada desde la que se realiza la conexión es fundamental. Los bancos son aún más serios: tienen GOST directos y los requisitos del Banco Central. La mejor manera de elaborar una especificación técnica, que aumentará drásticamente el precio, es remitirse directamente a los reglamentos internos que figuran en ella y no proporcionarla.
Tuvimos un caso en el que no pudieron firmar el contrato durante tres meses, el CIO colgó. El oficial de seguridad quería la implementación de GOST, queríamos que mostrara cómo se implementa ahora (sospechando que no era posible) y se ofreció a enviar una variante. No envió. En consecuencia, escribieron que “si dentro de los tres días no se reciben comentarios sobre el texto propuesto de la tarea técnica, entonces lo consideramos acordado”, y colocaron al titular de la empresa en la copia. IB envió una frase: "La instalación de actualizaciones y parches que eliminen vulnerabilidades críticas de SI debe realizarse a más tardar en 48 horas". Y eso es todo. Se puede decir que ya pasó.
En general, el tema de la seguridad de la información es grasiento y resbaladizo. Las personas seguras viven en su propio mundo. Todo es genial, los especialistas en infraestructura acordaron entre ellos, los contratistas lo están implementando. Y luego vienes a la empresa, y vas al primer departamento a negociar. Y allí se sientan en un taburete y hacen preguntas, porque nadie les ha informado de que algo está pasando.
Oh, sí, y no olvide tener en cuenta que los administradores deben tener acceso al objeto. Y es difícil cambiar piezas en el servidor de forma remota. Tuvimos en uno de los proyectos esperando de cinco a seis horas debido a que era necesario que el equipo global de la empresa (jefe de TI en India) aprobara las solicitudes de acceso físico del ingeniero.
La mesa de servicio es importante
Si desea ver aplicaciones en línea, no sea demasiado vago para registrar la posibilidad de integrar su sistema de Service Desk con el contratista o la necesidad de un portal web. De esta forma puede controlar de forma transparente la ejecución. Muchos clientes que trabajan por correo solo reciben el mensaje "Su ticket es muy importante para nosotros y lo resolveremos pronto". Y eso es todo, más allá de la caja negra. Y si el caso es crítico, todos quieren ver la prioridad, quieren ver quién está trabajando, microestados. Algunos pidieron llamar cada diez minutos. Ahora tenemos una persona dedicada que se para al lado del ingeniero, no le impide resolver el problema, pero al mismo tiempo informa al cliente sobre el estado de los casos críticos, cuando todo va, nada funciona y todos están nerviosos.
También fue muy bueno en un banco, donde las reglas para responder a los incidentes se describieron en un estándar interno. Afortunadamente, nos lo dieron. Había 300 páginas, escritas en 2005 y actualizadas en 2018 sobre un par de muletas. En general, entre otras cosas lógicas, existía un procedimiento de respuesta a las incidencias con la recogida de chat de personas importantes exclusivamente en Skype. Por la noche, debe llamar a todos los interesados y darse de baja allí. Y Skype no es tan animado. Tuve que reinstalarlo.
Los certificados no deben estar en la empresa, sino en los especialistas de su proyecto.
Un consejo sencillo: asegúrate de la profesionalidad del contratista, estos son certificados y experiencia laboral en la empresa.
El consejo más difícil es asegurarse de que estas personas estén en su proyecto. Hay empresas que escriben directamente a los TK que pueden participar en el trabajo y que no. Los alumnos no están preparados para trabajar con sistemas críticos. Puede escribirlo así: "Pruebas de especialistas por nuestros especialistas". He visto a un hombre acercarse a la pieza de hierro con un paquete de instrucciones. Dice: "Me encontraron en Yuda por 5 mil rublos".
Sucede que dieron una lista genial, ganaron, los muchachos vienen a la reunión de inicio, y hay otras personas que no participaron, no hay un par de competencias necesarias. Sé que hubo casos en el mercado en los que los equipos se cambiaron tres veces. En finanzas, el procedimiento es simple: hay listas de quienes pueden tocar la infraestructura. No admiten a nadie así, solo en la lista blanca.
Finalmente
Anote todos sus requisitos, tipos de trabajo, tipos de aplicaciones y haga un formulario en XLS con la imposibilidad de editar campos. Porque muy a menudo los proveedores intentan escribir algo por sí mismos y es imposible comparar más. Sé que el consejo es simple, pero rara vez alguien lo usa. Y luego se pierde una montaña de tiempo para averiguar quién prometió qué y quién es más rentable en precio.
Proyecto de muestra
Apoyamos una empresa minorista con tiendas en todas las regiones de Rusia (aumenta un 13% en el número de tiendas durante el año). La infraestructura consta de 1400 puestos de diferentes fabricantes, y las funciones que son críticas para el negocio operan sobre su base. TI soporta una gran cantidad de tareas de desarrollo. Allí, incluso el soporte de infraestructura ya es tan bueno que el departamento de TI por sí solo no puede hacer frente. Hay muchos equipos, es necesario administrar de alguna manera su ciclo de vida. En general, llevan cinco años subcontratando tareas rutinarias. Llevamos dos años con ellos. En tareas:
- Monitoreo 24 x 7 de la infraestructura informática y el entorno de virtualización.
- Informar a los responsables sobre los problemas en base a los resultados del seguimiento, para casos críticos en 15 minutos.
- Entrada de solicitudes de reposición de repuestos de fabricantes, reposición, informando sobre la restauración de obra.
- , / .
- 1400 CMDB.
- , CMDB.
Tenemos un equipo: la primera línea se encarga de monitorear y archivar las solicitudes de los proveedores, la segunda del trabajo de campo, la tercera de las áreas relacionadas (cuando el software de la aplicación no funciona y no está claro dónde está el problema). Hay un gerente técnico dedicado, supervisa y coordina a todos los especialistas técnicos; responsable por separado de la CMDB; un administrador de servicios independiente es responsable de la coordinación general del proyecto.
Sobre el contrato. Debo decir de inmediato que contiene un SLA para todo el trabajo, así como sanciones por incumplimiento. Existe la posibilidad de revisión trimestral de la lista de equipos soportados con un fácil recálculo del costo, ya que existe una lista de precios para cada unidad. También mantenemos reuniones periódicas con el cliente, donde discutimos los resultados del trabajo y los planes para el futuro.
El resultado es un ahorro de 5500 horas al año para el cliente, que fueron gastadas por sus propios empleados en proyectos de desarrollo. 99,9% de cumplimiento de SLA (hubo dos infracciones en el primer mes en términos de términos de notificación, se corrigieron debido a la retroalimentación periódica). La cantidad de notificaciones del sistema de monitoreo disminuyó en un 30%, gracias a la configuración óptima. Cuando se le preguntó acerca de cómo trabajamos, el CIO respondió: "No sabemos nada de usted". Entiende lo importante que es esto.
Plantilla de conocimientos tradicionales aquí . Hay 16 páginas de burocracia infernal, que le ahorrarán los nervios a todas las partes y muchos cientos de horas de trabajo, si lee y discute una vez antes de firmar.