DevOps o cómo estamos perdiendo salarios y el futuro de la industria de TI, segunda parte

El último artículo ya ha causado mucha indignación, creo que este artículo ya no será del agrado de muchos, en él describiré cómo ven los clientes a un ingeniero de DevOps.



Cuanto más tiempo pasa, más escucho que "este es el deber de los" devups ", las consultas a la base de datos quieren afinar los devups, adivinen cómo y con qué dependencias el software va a ser utilizado por el codificador - devups, evpn + bgp + ipsec + geo dns + autorización de red por certificados - devups, corregir errores de arquitectura y proponer opciones sin sangre - devups, convertir un pg_dump regular en replicación sincrónica - devups, ser psicoanalista para estaciones de servicio / CEO y equipo - devups.



Otra tendencia interesante es el balanceador de carga k8s + para cualquier estornudo. No hace mucho me ofrecieron incluso poner el equilibrador de carga en la base de datos, tal vez el promedio de carga disminuya y los discos estén menos cargados ... K8s es generalmente un tema separado, puede escribir 2-3 artículos sobre los mitos asociados con él.



Cada vez más, puede escuchar de las empresas que los desarrolladores e ingenieros se están emborrachando, que Sberbank ha establecido una pompa de jabón y que está a punto de suceder un milagro, y comenzaremos a trabajar como personas comunes por 60-80k de la mano de los senior. En las regiones, por supuesto, esto ya existe, pero allí todo era triste, pero aquí ya sueñan con todas las ciudades menos Moscú.



Es aún más divertido desde el mismo negocio escuchar lo perezosos que son todos, historias sobre lo inútiles que son los empleados y que necesitas buscar formas de no planificar el trabajo, la arquitectura, pensar en el futuro, sino de pegar código de baja calidad a la velocidad de la luz, porque luego los desarrolladores “escalan horizontalmente ", Sí, tenemos 1 consulta en la base de datos que cuesta el 15% de la capacidad del hardware y 5 consultas: un colapso, ¿y qué? ¡¡¡El escalado horizontal sin asignación de recursos nos salvará !!! - La verdad no se especifica cómo. Especialmente si la base de datos tiene una arquitectura bastante torcida, por ejemplo, PostgreSQL o Elasticsearch predeterminados.



¿Utiliza la tecnología según lo previsto? No es aburrido. Planificar la arquitectura, los esquemas de datos y su procesamiento: ¿por qué es costoso y lento? ¿Pero qué hacer? Hay una solución: contrate a un desarrollador y culpelo por todos los pecados mortales de su proyecto, sin olvidar agregar: todo funcionó exactamente antes de su llegada. Y los troncos mienten, todo funcionó !!!



Cada vez más, veo que proyectos bastante interesantes y prometedores están muriendo, incluso en la etapa de inicio, simplemente debido a juegos políticos. Me comunico con RM, que ya lleva seis meses sin vender un producto que puede traer a la empresa miles de millones de rublos al año, pero constantemente le ponen un radio. Todo el mundo está buscando formas de hacer desarrollo sin gastar en él, y la metodología DevOps se percibe cada vez más como una forma de volcar un producto que no funciona en la producción y cubrir las jambas con contenedores, equilibradores y talones, incluso si esto lleva a calificaciones bajas y una gran cantidad de negatividad, lo principal es ahorrar en desarrollo.

Como mostró la encuesta en el artículo anterior, para la mayoría de los visitantes de habr, los empleadores intentan tapar varios agujeros con 1 persona. Naturalmente, sin compensar estas obligaciones. Pero el problema es que la propia empresa sufre como resultado. Debido a los bajos salarios y la alta productividad laboral en relación al apoyo financiero y técnico, el negocio sobrevive, si, con una gestión como la de la CEI, intentaran hacer negocios en Japón o Estados Unidos, se habría arruinado hace mucho tiempo.



Muchas metodologías que nos llegaron de países desarrollados han sido completamente distorsionadas. Por ejemplo, Agile, Scrum, DevOps: las 3 metodologías requieren cambios significativos en los procesos comerciales para que funcionen, pero la gerencia en el CIS no está preparada para esto, espera combinar viejos hábitos y metodologías modernas, estamos en la cima a la antigua, y usted está en una forma moderna y efectiva. abajo. No tiene sentido implementar las 3 metodologías de abajo, la presencia de tarjetas, informes diarios, planes de 2 semanas y lanzamientos para cada línea de código no significa que haya implementado estas metodologías, significa que ha introducido procesos de informes adicionales que simplemente ayudan a encontrar al culpable y excusa. para la alta dirección. Solo es más difícil para el proyecto y las personas que comienzan a trabajar en tales condiciones implementar sus planes, porque el número de informes está creciendo significativamente más,que si no lo fueran.

Ahora hay bastantes artículos y discursos de extraños gerentes de TI que ya se ofrecen a pagar por los resultados, casi como antes por líneas de código, quitando tiempo del trabajo para pensar en la implementación, considerando que son 30-40 minutos, y luego simplemente escribiendo código. Al mismo tiempo, denos 2-3 semanas para pensar y calcular los costos y riesgos de las decisiones de gestión ... Como resultado, nos enfrentamos cada vez más con el hecho de que la calidad de los productos disminuye inevitablemente, por supuesto, esto no es solo un problema de la industria de TI, sino que en nuestra industria es especialmente agudo, porque las fallas se atribuyen a los programadores que, como "derrocharon 180 millones de rublos" Ya he visto 4 proyectos que, como resultado de este proceso, no cumplen con sus tareas, pero han gastado mil millones de rublos o más,pero como resultado, los perezosos especialistas en TI se volvieron culpables y sus más procedimientos regulatorios y de informes comienzan a corregir la situación. Se contratan gerentes adicionales para proporcionar funciones de supervisión y se reduce la nómina de los especialistas en TI. El número de decisiones que tomamos por nosotros mismos está disminuyendo y la responsabilidad y la rendición de cuentas están aumentando, lo que conduce a problemas aún mayores.



Debe trazar claramente las líneas de responsabilidad y minimizarlas, de lo contrario, simplemente se convierte en una víctima de cualquier juego político.



En el próximo artículo escribiré más sobre por qué DevOps y Agile, implementados desde abajo, nunca serán beneficiosos.