DevOps Best Practices 2020 Full Guide Final - En.es PDF

DevOps
si 2st mi
P 20realctices
academia de bellas
INEDO. COM
MEJORES PRÁCTICAS DEVOPS 2020
Tabla de contenido
ACERCA DE LA GUIA 3
EMPRESAS QUE CONFIAN EN INEDO AXIAN 4
GRUPO DEVOPS 10
TECNOLOGÍAS DE MENTES MÁS FELICES 18
MBCTG 22
QBURST 27
RELEASETEAM 32
FABRICANTES DE COHETES 36
CIENCIASOFT 39
APRENDE MÁS 41
PÁGINA 2
Sobre la guía
Creamos esta guía porque implementar DevOps en su empresa puede resultar abrumador. Ya sea que esté pensando en contratar a una consultora
para obtener ayuda, recién esté comenzando a aprender a asumir DevOps en su organización o necesite asesoramiento para mejorar sus procesos
actuales, la información de los expertos en esta guía puede ayudar a los líderes del equipo de desarrollo que buscan orientación. y evaluación de
soluciones DevOps.
Entrevistamos a las mejores prácticas de DevOps que ayudan a las empresas a realizar la transición a DevOps oa optimizar sus procesos de
DevOps. A todos se les hicieron preguntas individualizadas y los participantes pasaron mucho tiempo respondiéndolas para brindar una guía de
alta calidad a los lectores.
En esta guía, estas empresas brindan consejos prácticos sobre cómo realizar el cambio a DevOps y algunas de las mejores prácticas para temas importantes
de DevOps, como la implementación de la nube híbrida, la selección de las mejores herramientas de DevOps para su negocio, la evaluación del progreso con
las métricas adecuadas y la adopción de los aspectos culturales de DevOps.
Hicimos la investigación preliminar por usted, porque queremos que más empresas adopten DevOps
y brindar más valor a sus clientes y clientes, todo con las personas y las herramientas que ya tiene. A través de esta guía, conocerá las
consultorías y cómo comunicarse con cada una si ve el potencial para una colaboración exitosa. Estamos seguros de que esta guía
será un recurso valioso a medida que comience su viaje de adopción de DevOps.
PÁGINA 3
Empresas que confían en Inedo
PÁGINA 4
Axian
www.axian.com/
Las organizaciones se están moviendo cada vez más a la nube, pero luchan por saber cómo integrarla en sus procesos de DevOps.
¿Cuáles son algunas de las mejores prácticas sobre cómo hacer despegar esos esfuerzos?
Cada vez que una empresa decide pasar a una solución basada en la nube, siempre debe tener una hoja de ruta e hitos. No haga que sus hitos sean
demasiado elevados y concéntrese en obtener la parte más pequeña de su producto que proporcione un buen valor. Todos los recursos de la nube
deberían poder implementarse mediante la automatización. Asegúrese de poder implementar varios entornos (es decir, CI, QA, puesta en escena,
producción) e identificar los pasos manuales, documentarlos y, finalmente, automatizarlos. También querrá implementar una canalización automatizada de
compilación, prueba e implementación para que todas las solicitudes de extracción fusionadas con el maestro se implementen automáticamente en un
entorno de integración continua (CI).
¿Cuáles son algunas de las formas en que un software de nube deficiente puede dañar a las empresas? ¿Cómo deberían evaluar si su
software actual es adecuado para satisfacer sus necesidades?
Un software en la nube deficiente puede incurrir en costos ocultos, uno de los cuales es paralizar el desarrollo debido al temor de romper algo en
producción. Este temor se debe a varios factores: falta de CI / CD automatizados, pruebas unitarias y pruebas de integración insuficientes, servicios
estrechamente acoplados, incapacidad para aprovisionar fácilmente nuevos entornos en la nube, falta de una visión arquitectónica clara y pérdida de
características del producto. Antes de dar el salto a la nube, las empresas deben echar un vistazo a sus procesos actuales e identificar cualquier cosa
en sus prácticas de DevOps que falte o necesite mejorarse.
PÁGINA 5
¿Cuáles son algunos de los aspectos clave que las organizaciones deben tener en cuenta cuando crean un plan para la migración a la
nube?
Al migrar a la nube, las organizaciones deben considerar varios factores clave.

1. La organización debe analizar su experiencia técnica actual y determinar si un
proveedor de nube se alinea mejor con esa experiencia.
2. También deben determinar qué infraestructura local, si la hay, se requiere para un híbrido
configuración de la nube.
3. El plan de migración debe identificar todos los costos asociados con la migración a la nube.
a. Costos de desarrollo
si. Costo mensual promedio para ejecutar la infraestructura en la nube
C. Gastos personales de mantenimiento continuo
4. Cree un inventario de todos los sistemas de hardware y software que se verán afectados por la migración a la nube.
Cuando se trata de una configuración de nube híbrida, ¿cuáles son algunas de las cosas clave que las organizaciones deben hacer bien para
aprovechar al máximo la utilidad de su nueva infraestructura?
Cuando una organización decide optar por una estrategia de nube híbrida, debe considerar varios factores:
1. La confiabilidad y simplicidad de las interconexiones entre los recursos locales y en la nube. Cada
La conexión entrante y saliente debe ser muy confiable. Se debe configurar un sistema de alerta y monitoreo sólido para notificar
cuando surja un problema.
2. Prefiera los comandos y eventos asincrónicos sobre las conexiones síncronas.
3. Mida el rendimiento de los recursos antes y después de migrarlos a la nube.
En términos de personalización, ¿puede darme un ejemplo de una configuración o función personalizada que resolvió el problema
único de una organización?
Cuando se le pidió que implementara una plataforma para la puesta en marcha de un proveedor de identidad de rápido crecimiento, se decidió que la
plataforma debería admitir un enfoque desacoplado desde cero. Para admitir una capa de comunicación asincrónica, se utilizó un bus de servicio
basado en la nube. Usando SignalR, podríamos enviar notificaciones a los clientes cuando se completaron (o fallaron) comandos o eventos
particulares en el backend. El concepto de Saga ( mira el video de YouTube aquí) También se implementó, esto permitió que la lógica empresarial se
centralizara y se cambiara fácilmente a medida que cambiaban las necesidades empresariales. El proceso de desarrollo se basó en el tronco, y cada
confirmación en cada solicitud de extracción se creó y probó. Nos aseguramos de que los entornos basados en la nube fueran simples de
aprovisionar y configurar, y estuvieran aislados entre sí. Pasamos varias semanas para refinar las canalizaciones de CI / CD, pero al final del
proyecto, fue un tiempo bien invertido. Había alrededor de 10 entornos diferentes al final del proyecto CI, Mobile-CI, Demo, Demo-Sales, Staging,
PÁGINA 6
Production y varios entornos de desarrollador. Tener entornos de demostración dedicados permitió realizar demostraciones de sprint de manera
confiable y en paralelo realizar demostraciones para los posibles clientes del cliente a medida que la aplicación maduraba.
Desde una perspectiva de seguridad, ¿cuáles son las mejores prácticas que las organizaciones que se trasladan a la nube deben tener en
cuenta para evitar dolores de cabeza en el futuro?
Cuando se traslade a la nube, intente evitar las soluciones de seguridad personalizadas. Todos los principales proveedores de nube tienen soluciones para
la gestión de usuarios, autenticación, autorización, cifrado en reposo, cifrado de transporte y seguridad API. Utilice las ofertas de seguridad disponibles de
su proveedor de nube. Además, debe mantener las preocupaciones de seguridad separadas de su código fuente, la seguridad debe ser configurada y
controlada principalmente por el equipo de Operaciones. Todas las contraseñas, certificados y claves almacenados deben rotarse de forma regular.
Mencionas la necesidad de resultados sostenibles. ¿Hay alguna señal de alerta que las organizaciones puedan tener en
cuenta que indique que algo sobre su enfoque de DevOps debe cambiar?
Las organizaciones siempre deben realizar un seguimiento de la cantidad de tiempo que tarda una característica en entrar en
producción, esto se conoce como tiempo de ciclo. Cuando empiece a notar un aumento en el tiempo del ciclo, debe intentar
identificar qué áreas del proceso de desarrollo se están desacelerando. Podría ser el tiempo que le toma al control de calidad validar
las funciones, o podría deberse a definiciones inadecuadas de la historia del backlog, o podría deberse a la rotación del
PÁGINA 7
desarrollador. Una vez que haya identificado qué áreas del proceso de desarrollo causan la desaceleración, deben unirse como un
equipo unido para tratar de solucionar los problemas. Si se debe a historias de mala calidad, entonces debe ser más intencional en
dedicar más tiempo durante las sesiones de preparación y perfeccionamiento de la acumulación. Si se debe a una ralentización del
control de calidad,
Además, siempre tenga en cuenta la relación entre los equipos de "Desarrollo" y "Operaciones". Siempre deben tener una buena relación y
desconfiar de nosotros y de la mentalidad. De manera óptima, ambos equipos están bajo la misma jerarquía de gestión.
El sitio web de Axian habla de "adopción cultural". ¿Cuáles son algunas de las actitudes culturales comunes que ve en las
organizaciones que implementan DevOps de manera efectiva?
Las organizaciones deben tener una aceptación de DevOps de arriba hacia abajo para implementar con éxito una cultura de DevOps que ofrezca
valor al cliente de manera constante con tiempos de ciclo reducidos. A menudo, si una o más personas o departamentos no aceptan DevOps, habrá
fricciones y la imposibilidad de enviar funciones con tiempos de ciclo bajos. Si la gerencia o los ejecutivos no son capaces de comprender la filosofía
de DevOps, entonces depende de la gerencia media "capacitar" a los ejecutivos para enseñarles el por qué, el cómo y el cómo surge del enfoque
DevOps. Este enfoque de capacitación también puede ser facilitado por desarrolladores y otros colaboradores individuales, quienes pueden transmitir
a los ejecutivos la justificación de DevOps de por qué el cumplimiento de ciertas prácticas de DevOps es necesario para la salud general y el éxito de
la organización.
¿Cómo sugiere que las empresas que no tienen una cultura DevOps estén construyendo una?
Si su organización carece de una cultura DevOps adecuada, no intente cambiar el mundo de la noche a la mañana. Comience con metas de
pequeños pasos. Cree una visión personal de dónde piensa que debe llegar la cultura y los hitos necesarios para llegar allí. Es útil formalizar
esta visión en un documento. Crea metas que se adhieran a
INTELIGENTE (específico, medible, alcanzable, relevante, de duración determinada). Para los desarrolladores, recomendaría trabajar en las prácticas que se enumeran a
continuación (aproximadamente en este orden):
1. Mata tu ego y estima a los demás más grandes que a ti mismo
2. Implementar el desarrollo basado en troncos, evitando ramas de larga duración (más de 1 día de antigüedad)
3. Proteja su rama principal y requiera solicitudes de extracción para facilitar la discusión y las revisiones de código
4. Comience a escribir buenas historias de trabajos pendientes, que tengan criterios de aceptación claros
5. Prioriza tu backlog
6. Identifique al propietario de su producto (si no tiene este rol, hable con la gerencia para asignar este rol a alguien)
7. Identifica tu límites de servicio

8. Proteja su acumulación de funciones. Todas las solicitudes de funciones deben pasar por el propietario del producto y
priorizado
9. Automatiza tus compilaciones para la rama troncal (compila y prueba unitaria cada confirmación)
PÁGINA 8
10. Automatice la implementación de la rama troncal cada compromiso en una Integración Continua dedicada
(CI) entorno
11. Automatice la ejecución de un conjunto de pruebas de humo contra el entorno de CI
12. Automatice las compilaciones para las ramas y las solicitudes de extracción (compilación y prueba unitaria en cada confirmación)
13. Comprometerse con el proceso de desvinculación de sus servicios

Para los gerentes, recomendaría facilitar las prácticas de desarrollo enumeradas anteriormente. Eso incluye priorizar el trabajo pendiente para incluir este
trabajo en los sprints. Los gerentes y arquitectos también deben proporcionar una visión general de DevOps que incluya lo siguiente:
1. "Capacite" a los equipos ejecutivos sobre DevOps

2. Asegúrese de que la arquitectura esté débilmente acoplada
3. Empoderar a los equipos para trazar su propio rumbo
tener éxito
4. El seguimiento debe ser una alta prioridad para
facilitar más automatización

5. Asegúrese de que se implementen las notificaciones proactivas de los entornos de producción
6. Construye tus equipos parecerse a pequeñas organizaciones de software
Si pudiera darles a las empresas un consejo sobre la adopción de DevOps, ¿cuál sería?
En mi opinión, todas las empresas se embarcan en el viaje de DevOps. Obtendrá múltiples recompensas, como:
1. Mayor satisfacción laboral de los empleados
2. Menos miedo a realizar cambios significativos
3. Entregue valor a los clientes en menos tiempo
4. Aumente la productividad del desarrollador
5. Mejora de la comunicación entre equipos
6. Mayor cohesión de los empleados
7. Alineación, enfoque y visión corporativos
Mark Johnson es un arquitecto de soluciones que trabaja con una variedad

de empresas para crear soluciones de software personalizadas para resolver
problemas comerciales desafiantes. Él cree que es necesario un enfoque integral
de DevOps para crear soluciones de software que sean escalables y puedan
evolucionar con las necesidades comerciales. PÁGINA 9
Contáctenos
Axian Inc.
9600 SWNimbus Ave. Suite 200 salesinfo@axian.com 503-644-6106 (teléfono)
Beaverton, OR 97008 EE. UU. 503.643.8425 (fax)
Desacoplamiento, Arquitectura y Equipos

Udi Dahan - Si (lógica de dominio), ¿CQRS o Saga?
Grupo de DevOps
www.devopsgroup.com/
En su discurso de apertura en el que describía su trabajo con los sistemas BAE, declaró que el primer paso hacia la adopción de
DevOps era pasar a un modelo de entrega centrado en el producto para solo unos pocos productos. ¿Puede explicarnos las etapas
iniciales de ejecución de esa estrategia? ¿Cómo pueden las organizaciones replicar ese proceso?
El primer paso es identificar cuál es el producto. Roman Pilcher, una figura muy conocida en el espacio de Gestión de productos, afirma que
un producto es "algo que crea un valor específico para un grupo de personas, los clientes y usuarios, y para la organización que lo
desarrolla y lo proporciona". En BAE Systems, comencé con esta definición en torno a aplicaciones que pronto se reorientaron a cadenas de
valor. La fase final habría sido alinearnos con los resultados del cliente con los que comenzamos a experimentar.
El siguiente paso es establecer un equipo de larga duración en torno al producto con todos los roles necesarios para hacer el trabajo. Este equipo operaba el
principio de "tú lo construyes, tú lo ejecutas" y utilizó la regla de oro del "equipo de dos pizzas" de Amazon. Asignamos roles como propietario de producto, líder
de entrega de producto, analista de producto, líder técnico de producto e ingenieros de producto al equipo. Para muchas personas, esto necesitaba una
redefinición de su función y, como resultado, necesitábamos desaprender lo que sabíamos y aprender lo que ahora necesitábamos saber.
Como parte de la reorganización, tomé a mi organización (y a mí mismo como su líder) a través de un programa de capacitación y
entrenamiento sobre principios y prácticas Agile y DevOps. Esto incluyó la capacitación seguida por la implementación con el apoyo de
coaching y luego una revisión con más capacitación, implementación, coaching, etc. Esto permitió a mis equipos aprender en pequeños lotes,
aplicar y revisar; era casi un enfoque ágil para la capacitación y el coaching. Ahora uso este patrón cuando me relaciono con nuevos clientes.
DevOps requiere un cambio de mentalidad y se necesita consistencia y perseverancia para cambiar y luego evitar que la goma elástica vuelva a
las formas antiguas.
Lo anterior llevó a la formación de un nuevo lenguaje con palabras como acumulación e historia entrando en el vocabulario y vimos cambiar las métricas de
rendimiento; inicialmente esto empeoró a medida que los equipos abordan la deuda técnica y de procesos, pero luego comenzó a acelerarse a medida que el
negocio y la tecnología comenzaron a funcionar como uno.

PÁGINA 1 0
Reflexionando sobre mi viaje y experiencia con varios clientes, ahora he identificado 5 áreas que una organización debe abordar:
• Estrategia: trabajar al revés desde el cliente

• Organización: del proyecto al producto
• Cultura: Establecer un entorno generativo centrado en la seguridad psicológica, el aprendizaje y la autonomía.
• Formas de trabajar: reducción de riesgos mediante lotes más pequeños y ciclos de retroalimentación más rápidos
• Tecnología: utilización de tecnologías modernas para construir canales de entrega continua y plataformas en la nube para acelerar
la entrega de nuevas funciones mientras se mejora la estabilidad del producto.
La transición del estado actual al estado futuro se ilustra a continuación:
Su discurso de apertura también mencionó la necesidad de que los ingenieros estén "al frente" de las organizaciones. ¿Puede describir lo que
quiere decir con eso, por qué es importante y cómo los principios de DevOps permiten que las empresas lo hagan realidad?
PÁGINA 1 1
Si tuviera que trazar los flujos de información entre usuarios e ingenieros en una empresa tradicional, habría muchas transferencias y
dependencias. Los ingenieros de software rara vez llegan a ver cómo funciona su código en producción. El ingeniero de operaciones
dirige la producción pero se siente impotente porque no puede cambiar o mejorar el servicio.
En las formas de trabajo ágil y DevOps, el negocio y todas las funciones de TI trabajan en estrecha colaboración para un objetivo común en equipos
pequeños. Si el equipo está construyendo y brindando soporte al producto, los ingenieros podrán ver cómo los usuarios usan su código. Hablarán
regularmente con los clientes y responderán con regularidad a los comentarios, fallas y aprendizaje.
War and Peace in IT de Schwartz describe este panorama muy bien y se ha tratado a las personas de TI como si no fueran parte del
negocio. “Negocios y TI” son entidades separadas y la gente de tecnología habla un idioma diferente y los negocios deben estar protegidos
de ellos. Esto ya no es verdad; La TI se está convirtiendo cada vez más en el negocio y los ingenieros pueden utilizar las capacidades
técnicas de la nube y la automatización para traducir el lenguaje del negocio al lenguaje del código casi instantáneamente.
El papel del ingeniero es traducir el modelo de negocio en código, de ahí la necesidad de asegurarse de que estén comprometidos, alineados y
capacitados para lograr el objetivo de la empresa.
Su consultoría pone un gran énfasis en la cultura DevOps como una forma de "modernizar las formas de trabajar".
¿Cómo le parece una cultura DevOps eficaz, cuáles son las similitudes y diferencias entre las organizaciones y cómo
hacen las empresas para crear una que les funcione?
Esta es una gran pregunta y creo que está aprovechando nuestra salsa secreta.
En Kung Fu Panda, el "uno" puede abrir el Rollo del Dragón para identificar cuál es el verdadero poder y no hay nada en él, pero
hay ... un reflejo. Eres el Rey Dragón, eres el poder, eres el ingrediente secreto.
Tenía varios equipos propios, ahora trabajo con varios clientes y soy anfitrión de DevOps Manchester y trabajo con empresas de
vanguardia como Auto Trader y ao.com. Cada organización, cada equipo tiene su propia cultura. Pero la cultura tiene una característica
común: las personas confían entre sí. La confianza es un componente clave.
¿Cómo se crea la confianza? A través de la relación. ¿Cómo se forman las buenas relaciones? Pasando tiempo juntos, compartiendo
información, fracasando juntos y aprendiendo juntos.
Westrum en su topología de cultura organizacional comparte cómo las diferentes culturas organizacionales comparten información en un entorno de
seguridad. Una cultura generativa aceptará las malas noticias y aprenderá de ellas. Fomentará el flujo abierto de información y el intercambio, se
PAGINA 12
compartirán los riesgos y se adoptarán las novedades.
Intentamos llevar al equipo y la organización (incluido el liderazgo) a través de un viaje en el que comprenden y se alinean con
objetivos y medidas comunes respaldados por una comprensión más profunda del "por qué" existen. Luego les mostramos cuál
es su trabajo, la complejidad de su entorno y cómo
el trabajo fluye a través del equipo (s) con el fin de entregar valor al cliente. En este momento, la mentalidad y el corazón están cambiando: pueden ver
la rueda de hámster en la que están corriendo y reconocer la necesidad de cambiar para seguir adelante. Luego nos ponemos manos a la obra y los
acompañamos para capacitarlos y entrenarlos en nuevas formas de trabajar, mientras nos involucramos con el liderazgo para crear el entorno adecuado
para que sus equipos prosperen.
Después del dolor inicial y algunos contratiempos, los equipos comienzan a formar una cultura de responsabilidad, alineación, intercambio y enfoque
en el cliente, pero cada uno es diferente. Un verdadero líder sabrá cómo cultivar diferentes plantas en el mismo jardín.
Su sitio web cita estadísticas del Informe State of Agile de que el 44% de los encuestados declaró que el “patrocinio y el apoyo de gestión
inadecuados” son un problema que obstaculiza DevOps. ¿Cuáles son algunas de las cosas clave que puede hacer la administración para
asegurarse de que no se conviertan en una limitación para la adopción?
“¿Dónde está el plan?”, “Muéstrame el gráfico de Gannt”, “¿Dónde está el caso de negocio del proyecto?”, “¿Has pasado por el proceso de gobernanza del
ciclo de vida?”, “Quiero ver a las personas organizadas en plan, construcción y operar funciones ”,“ No me muestres el MVP, ¿cuándo obtendré todas las
funciones? ”,“ No quiero que la gente aprenda en el trabajo, pueden ir a un curso de capacitación si lo necesitan ”,“ ¿La revisión de la preparación
operativa identifica todos los controles y equilibrios que un equipo debe cumplir para implementarse en producción? "," ¿Cuántos recursos más se
necesitan para que esto funcione? "," ¿Dónde está la única garganta para ahogar (o panza para presionar)? "
Todos hemos escuchado algunas o todas estas declaraciones antes. El liderazgo debe aceptar el cambio casi antes que el resto de la
organización. Un equipo puede comenzar de a poco y unirse para ofrecer valor a pequeña escala, pero sin el patrocinio del liderazgo. Eso es
como iniciar un incendio en un edificio equipado con detectores de humo y un sistema de rociadores: la iniciativa se apagará.
Un líder senior y un patrocinador comercial deben apagar el sistema de rociadores, incluso si es solo para un piso o una habitación para
empezar. Mencioné esto en mis artículos recientes, el DevOps Playbook, donde dije: "¿Cómo podría ser parte de la solución, cuando era parte
del problema?". Necesitaba cambiar. Mi jefe necesitaba cambiar.
¿Qué puede hacer la gerencia? Necesitan empezar a leer, necesitan un entrenador de liderazgo y necesitan formación y emprender el viaje con
sus equipos. Sin embargo, es como Alcohólicos Anónimos: debes admitir que tienes un problema y luego no tengas miedo de pedir ayuda. Esto
es lo que hice. La lista de libros que leí está en Goodreads. Para los líderes, recomendaría específicamente; Phoenix Project (Kim), Lean Start-up
PÁGINA 1 3
(Ries), Radical Candor

(Scott), Guerra y paz en TI (Schwatrz), Equipo de equipos (McChrystal), The Goal (Goldratt), Un asiento en la mesa (Schwatrz), Dar la vuelta al
barco (Marquet), Empezar con el por qué (Sinek), Potente (McCord), Proyecto a producto (Kirsten), Bueno a excelente (Collins), Legado (Kerr),
Scrum (Sutherland).
El desafío inicial para muchas organizaciones empresariales es romper el sistema monolítico heredado. ¿Cuáles son algunos de
los problemas recurrentes que ve al comienzo de este proceso? ¿Cómo les dices a tus clientes que los superen?
Vemos esto mucho y, a veces, se divide en dos partes: monolitos y deuda técnica. Los monolitos también tienden a estar conectados a un
ecosistema de otros sistemas (incluidos otros monolitos). Esto hace que el cambio sea muy difícil y el equipo de operaciones se esfuerza por
mantener estos sistemas en funcionamiento y se resisten a cualquier cambio. Mientras tanto, la empresa habrá desarrollado múltiples proyectos,
todos dirigidos al mismo monolito. Hay mejores palabras para esto, ¡pero puede ser un desastre!
¿Qué aconsejamos? Como con cualquier cosa, comience con algo pequeño. ¿Se pueden tratar los componentes internos del monolito como
un subsistema o un módulo? ¿Se puede aislar eso en absoluto? ¿Puede alinear el trabajo, el equipo y los clientes con estos módulos,
esencialmente creando mini flujos de valor? ¿Se puede entregar parte del trabajo en lotes más pequeños sin afectar a otros subsistemas e
interfaces externas?
En algún momento, las respuestas a estos serán no. Entonces necesitamos avanzar hacia una estrategia técnica y capacidades asociadas
para ayudarnos. Una de estas estrategias es desarrollar un marco de prueba de automatización integral que realice una prueba de
regresión e integración completa; esto permitirá dividir el trabajo en lotes más pequeños y acelerarlo. Otra estrategia es establecer una
capa de API que se forma entre los diferentes sistemas de la empresa y esto crea una capacidad que le permite cambiar el monolito sin
afectar el ecosistema más amplio. También le permite comenzar a mover cargas de trabajo / módulos / subsistemas a aplicaciones más
pequeñas o microservicios fuera del monolito; con el tiempo, esto eliminará el monolito por completo o reducirá el monolito a una huella
heredada mucho más pequeña. Esto también se conoce como patrón estrangulador.
En el lado de las TI, la deuda técnica es algo con lo que muchas organizaciones empresariales luchan cuando rompen un
monolito. ¿Cuáles son algunas de las mejores prácticas para liquidar esa deuda mientras se pasa a los microservicios?
La mejor forma es dar tiempo a los equipos. Una vez que estén alineados con un objetivo común, integrados como un equipo multidisciplinario y
estén visualizando y midiendo el trabajo, podrán ver sus limitaciones. Demasiados incidentes, acumulación de problemas, cambios difíciles, rotura
PÁGINA 1 4
de otros componentes del servicio, etc. afectarán su flujo. Permita que el equipo se concentre en los Cuatro Tipos de Trabajo identificados en el
Proyecto Phoenix por Gene Kim y luego priorice los “proyectos internos” como cualquier otro trabajo. El equipo irá más lento antes de ir más
rápido, pero está bien: el liderazgo debe proporcionar ese entorno
¿Hay algún desafío que vea que sus clientes pasan por alto o minimizan constantemente cuando adoptan un enfoque DevOps completo?
¿Cómo pueden las empresas trabajar para descubrir sus propios puntos ciegos, de modo que no se sorprendan con un problema durante el
proceso de transición?
Yo diría que los puntos ciegos clave incluyen:
• la gente empieza primero con las herramientas y la tecnología antes que con la gente y la cultura. Estos deben hacerse juntos, no por
separado.
• el liderazgo querrá que la organización cambie y no se considere a sí mismo

• La gerencia intentará cambiar el diseño de la casa sin cambiar los cimientos: los procesos de gobernanza, las construcciones
financieras, las estructuras de gestión, los KPI, los incentivos para los empleados, etc. deben cambiar junto con las formas de trabajo y
las capacidades tecnológicas.
• intentarán hacer un gran cambio sobre comenzar con algo pequeño, aprender y crecer.
Cambiar la organización ahora se parece más a Candy Crush que a CMMi: se trata de una mejora continua sin un final aparente.
Trabajamos con clientes que intentan iniciar el juego y con clientes que necesitan ayuda para pasar del nivel 2 al 3 (o de 200 a 300).
Háblenos sobre las herramientas DevOps. ¿Qué papel cree que desempeñan en el panorama general de DevOps cultural? ¿Cuáles son algunas de
las mejores prácticas que pueden seguir las organizaciones para aprovecharlas al máximo?
Me encanta el libro Good to Great, Collins, en el que afirmamos que la tecnología es un acelerador de impulso, no un generador de impulso:
construye el volante y luego usa la tecnología para acelerar. Nos equivocamos todo el tiempo.
Comencé con una pared, algunas pizarras mágicas y algunos post-it para crear un tablero Kanban con límites de WIP respaldado por algunas prácticas ágiles
básicas y monitoreado a través de un cuadro de mando y un diagrama de flujo acumulativo. En cualquier otro oficio, empezamos de a poco, empezamos de
forma manual; aprendemos antes de utilizar más herramientas industriales y técnicas avanzadas. Nos equivocamos en los negocios todo el tiempo -
Personas e interacciones sobre procesos y herramientas - Manifiesto ágil.
Las herramientas vienen después y puede haber algunas herramientas que la empresa debería exigir, pero hay muchas que deberían dejar a los equipos
para que las resuelvan y utilicen. Lograr el equilibrio a veces es difícil, pero el principio es comenzar lento, comenzar manualmente, desarrollar
comprensión, practicar, dominar, automatizar.

PÁGINA 1 5
Dicho esto, hay una serie de organizaciones con las que he trabajado y que pueden necesitar aliviar algunas de sus mayores limitaciones
utilizando la tecnología. Capacidades como API, plataformas en la nube, pruebas automatizadas y canalizaciones de entrega continua pueden
volverse esenciales para lograr un trabajo que llevaría meses a minutos.
Ha trabajado con el sector de los seguros, en concreto. ¿Cómo ayuda DevOps al legado?
las empresas se defienden de disruptores advenedizos? ¿Y cuáles son algunas de las prácticas de DevOps que ha encontrado que son
particularmente importantes para lograr ese objetivo?
El sector asegurador se enfrenta a grandes desafíos y he hablado con líderes en el campo, he asistido a mesas redondas y he estado en
conferencias específicas. Las organizaciones tradicionales necesitan ser más receptivas con la capacidad de entregar productos a sus clientes,
quienes ahora exigen más, quieren más personalización y tienen mayores expectativas de lo que les traerá “tranquilidad”. Esto no se limita a las
empresas B2C, sino que también se aplica a las empresas B2B (aunque de forma menos agresiva).
Una parte clave de todo esto son los datos y poder usar sus datos mientras interactúan con el cliente, pero también usan estos datos para formar nuevos
productos y servicios. La capacidad de administrar datos requiere las plataformas digitales adecuadas y debe ejercer el uso del aprendizaje automático y
la inteligencia artificial. Las empresas saben que tienen un largo camino por recorrer y se ve que las organizaciones tradicionales acercan la TI al negocio
(como parte del negocio), reestructuran sus contratos de abastecimiento de TI e in-source en algunas áreas y crean pequeños servicios multifuncionales.
equipos que brindan resultados comerciales mientras aprovechan el poder de la tecnología, no de una manera "big bang" sino más bien en una evolución
de la capacidad técnica a lo largo del tiempo y en respuesta a las necesidades del usuario / cliente.
Aquí es donde los equipos alineados con productos, las formas ágiles de trabajar, las plataformas en la nube y la automatización combinados brindan las
capacidades necesarias para competir y ganar en este mercado vibrante.
Si pudiera dar un consejo a un gerente o equipo empresarial que está a punto de embarcarse en un viaje de adopción de
DevOps, ¿cuál sería?
Ok, tiendo a ver una versión de mí en la mayoría de los líderes que conozco cuando comenzaba mi viaje: "¿Por dónde empiezo?" Entonces, si estuviera hablando
conmigo mismo hace 4 años:
1. Esto va a tomar algunos años, ¡abróchate el cinturón!
2. Va a empeorar antes de mejorar, ¡ten fe!

3. Obtenga el patrocinio ejecutivo, de lo contrario no irá a ninguna parte rápidamente.
4. ¡No puedes hacer esto solo, encuentra a Yoda! (o Erik si ha leído el Proyecto Phoenix) - DevOpsGroup
fueron mi Yoda ...
5. Consiga a las personas adecuadas en los asientos adecuados del autobús y luego descubra a dónde ir, construya de manera excelente
equipos - ¡invaluable!
6. Conviértete en el evangelista de la organización, lee, aprende, comparte, aplica, repite

PÁGINA 1 6
7. Afronte los problemas difíciles de frente, hombre arriba.
8. No tengas miedo, ten coraje, sé valiente

9. Cree en ti mismo y rodéate de los 'generales' adecuados: crea un espacio seguro
10. Tómese un descanso: saque la basura de su diario, pase tiempo con los equipos y el cliente,
11. Vete a casa antes, haz otras cosas fuera del trabajo, ¡sé tú mismo!
Raj Fowler
Director de servicios empresariales
Años en DOG: 1 año 6 meses
Raj Fowler es una autoridad líder en cómo las organizaciones se reorientan para competir y ganar en la economía digital. Raj tiene un
historial de cambio organizacional en un negocio aeroespacial y de defensa global con un profundo conocimiento de los desafíos que
enfrentan las grandes empresas. Empleando los principios de DevOps y Agile, Raj ha establecido con éxito productos que han permitido una
ventaja competitiva al armonizar la velocidad y la estabilidad, aprovechando tanto el poder de las personas como el poder de la tecnología.
Raj, como Director de Servicios Empresariales en DevOpsGroup, trabaja con clientes empresariales para satisfacer la necesidad de velocidad. La
aceleración del trabajo se logra incorporando prácticas de DevOps respaldadas por plataformas en la nube y canalizaciones de entrega continua, lo que
da como resultado la transformación de "meses" en "minutos".
Contáctenos
PÁGINA 1 7
Cardiff Londres 0800 368 7378

Team@devopsgroup.com para consultas generales
Piso 22, Capital Tower Subir,
Academy@devopsgroup.com para consultas sobre cursos de formación
Greyfriars Road Cardiff 41 Luke Street,
Talent@devopsgroup.com para consultas de contratación
Gales Shoreditch
CF10 3AG EC2A 4DP
Tecnologías de las mentes más felices

www.happiestminds.com
Una de las especialidades de Happiest Minds es la configuración de la nube híbrida. ¿Cuáles son algunas de las mejores prácticas que deben tener
en cuenta las empresas al ejecutar una nube híbrida?
Creemos que hay muchas prácticas que las empresas deben adoptar en función de nuestra experiencia como proveedor de servicios administrados y SI en
este espacio. Vemos que las organizaciones se encuentran en varios niveles de madurez en la adopción y gestión de la nube híbrida. Muchas de las
mejores prácticas se destacan a continuación:
Monitoreo de TI unificado Habilitación de desarrolladores
• Descubrimiento profundo para la asignación de • Integración DevSecOps

dependencias de aplicaciones • Automatización de implementación de código e infraestructura
• Monitoreo inteligente de infraestructura y aplicaciones • SDLC seguro

• Análisis avanzado para información operativa
• Automatización basada en datos y autorreparación Seguridad y cumplimiento
• Seguridad de aplicaciones, API, SO y redes
Aprovisionamiento de autoservicio • Gobernanza de configuración y cumplimiento
• Catálogos de servicios • Gestión de identidad y acceso
• Portales de autoservicio • Integración SIEM
• Aprovisionamiento y desaprovisionamiento automatizados de
recursos Informes y análisis

• Paneles para CxO, administradores de TI y usuarios finales
Manejo de costos • Informes de disponibilidad, rendimiento, capacidad, costos, SLA y
• Visibilidad de los costos cumplimiento
• Facturación y medición • Información basada en análisis
• Contracargo y Show-Back
PÁGINA 1 8
Cuando se trata de proteger una nube híbrida, ¿cuáles son algunos de los grandes desafíos a los que ve que se enfrentan
sus clientes y cómo los ayuda a superarlos?
Muchos de nuestros clientes enfrentan desafíos con respecto a las necesidades de cumplimiento normativo (por ejemplo, GDPR), estableciendo el nivel adecuado de
controles de seguridad y cumplimiento para aplicaciones e infraestructura de nube privada, pública e híbrida, integración de múltiples herramientas (por ejemplo,
herramientas existentes para -Herramientas SaaS / SaaS en la nube y locales para infraestructura en la nube), brechas en habilidades / procesos / herramientas cuando
se trata de operaciones y monitoreo de seguridad. Happiest Minds adopta un enfoque basado en consultoría para abordar los desafíos de seguridad. Contamos con una
práctica de Gobernanza, Riesgo y Cumplimiento (GRC) para comprender el panorama y la madurez TAL CUAL y proporcionar una hoja de ruta para el estado FUTURO.
Para abordar cualquier brecha en la seguridad que pueda tener el cliente, ofrecemos un espectro completo de servicios como servicios de ciberseguridad, administración
de identidades y accesos, seguridad de datos, administración avanzada de amenazas.
A medida que las empresas adoptan cada vez más el modelo "nativo de la nube", vemos una gran oportunidad para la integración de DevSecOps para aquellos en
el viaje a la nube híbrida.
¿Qué tipo de métricas recomienda que utilicen sus clientes y qué tipo de información procesable generarán?
Desde una perspectiva de monitoreo, recomendamos que la disponibilidad de las aplicaciones, el rendimiento, la capacidad y el costo de consumo de la
nube se monitoreen con umbrales para activar alertas. Cada vez más, recomendamos el uso de herramientas de monitoreo con análisis para generar
información para abordar la naturaleza dinámica de la infraestructura de la nube y los patrones de consumo. Los conocimientos pueden estar relacionados
con el rendimiento de la aplicación, la detección de anomalías, los costes, el cumplimiento y la planificación de la capacidad. Aprovechamos nuestra
plataforma ELLIPSE para monitoreo + análisis cuando brindamos servicios administrados a los clientes.
¿Cómo pueden las empresas evaluar sus propios procedimientos de gestión de incidentes? ¿Cuáles son algunas de las mejores
prácticas que deberían buscar implementar?
Adoptamos un enfoque holístico en la configuración operativa de TI. La gestión de incidentes (IM) es una parte de las operaciones de TI. Las
empresas pueden comenzar a evaluar la eficacia de la mensajería instantánea creando un marco que involucre procesos, herramientas, tecnologías
y personas. Por lo general, comienza asegurando que esté disponible un inventario de infraestructura preciso seguido de una herramienta de
monitoreo con una buena cobertura de la infraestructura. Luego viene la herramienta Service Desk con flujos de trabajo de mensajería instantánea
definidos para adaptarse a las necesidades operativas y comerciales de la empresa. Con estos conceptos básicos en su lugar, las empresas
pueden evaluar su necesidad de automatizar aún más. Por lo general, implica la integración entre herramientas para la emisión automática de
tickets, la reducción del ruido de alerta, la correlación de eventos, las tareas de automatización de 0,25, etc.
PÁGINA 1 9
en un papel blanco lo hizo en servicios de infraestructura administrada, escribió que liberar al personal interno del trabajo
operativo debería ser un objetivo de las organizaciones. ¿Puede dar un ejemplo de una tarea que a menudo ayuda a sus
clientes a eliminar y cómo lo hace?
Ofrecemos servicios de infraestructura administrada que permiten a los equipos del cliente enfocarse en objetivos más estratégicos (por ejemplo,
transformación de la nube) y reducir el tiempo dedicado a tareas operativas diarias como monitoreo, corrección de incidentes, parches,
actualizaciones del sistema, etc.
¿Dónde ve el papel de las herramientas de DevOps en una configuración de nube híbrida? ¿Qué tipo de funcionalidad deberían buscar las
empresas cuando deciden adoptar una solución de herramienta?
En nuestra experiencia, a menudo vemos que DevOps o DevSecOps se adoptan en entornos que se vuelven nativos de la nube con la implementación
de una arquitectura de microservicios. Vemos barreras significativas para la adopción de DevOps en entornos heredados o tradicionales donde la
infraestructura no se ha estandarizado y virtualizado para facilitar las actividades de aprovisionamiento / desaprovisionamiento automatizadas. Desde
una perspectiva de "Operaciones", la mayoría de los clientes buscan herramientas que ayuden a automatizar la implementación, la gestión de la
configuración y la automatización de la supervisión.
¿Cuáles son las métricas clave de rendimiento que recomienda que las empresas sigan y cómo deberían utilizarlas para aumentar el
rendimiento?
Desde la perspectiva de la infraestructura, medir la E / S de la CPU, la memoria y el almacenamiento, la latencia de la red y el rendimiento de las consultas de la base de
datos son clave para asegurar cómo la infraestructura subyacente afecta el rendimiento de la aplicación. Para las aplicaciones mismas, medir el tiempo de actividad de la
aplicación, los tiempos de respuesta, el número de sesiones activas y las tasas de error de la aplicación puede ayudar a proporcionar información sobre los niveles de
experiencia del usuario. Las técnicas de Monitoreo de usuarios reales y Monitoreo sintético también pueden ser útiles en ciertos casos de uso.
Su sitio web indica que su Plataforma ELLIPSE puede reducir los costos operativos de la infraestructura de TI hasta en un 30%.
¿Qué están haciendo mal las empresas que les permite ofrecer una mejora tan grande?
La plataforma por sí sola no puede aportar tales mejoras en la productividad. Es una combinación de optimización / simplificación de procesos, cobertura de
monitoreo, reducción de esfuerzos a través de autoservicio / autocuración / autocorrección / automatización de tareas y conocimientos prácticos que conducen a
mejores decisiones.
PÁGINA 2 0
La plataforma ELLIPSE también realiza una "automatización basada en políticas". ¿Puede dar un ejemplo de cómo se ve?
Un ejemplo simple puede ser la rotación de registros automatizada: si el tamaño del archivo de registro supera los X GB, el motor de automatización puede generar
un controlador de acciones para iniciar la rotación de registros.

Si tuviera que dar a las empresas un solo consejo sobre la infraestructura de TI, ¿cuál sería?
La complejidad de administrar infraestructura privada, pública e híbrida ha aumentado debido a la multitud de tecnologías, herramientas y
habilidades requeridas en los últimos años. Para simplificar la gestión de la infraestructura, es relevante una visión holística junto con la aplicación,
en la que la estandarización de procesos, tecnología y configuración es imprescindible antes de que se pueda introducir la automatización.
Girish Chandangoudar:
Gerente general
Jefe de Servicios de Gestión de Infraestructura
Chandangoudar femenino tiene más de 25 años de experiencia en servicios de telecomunicaciones y TI

empresarial que abarcan servicios de Internet, operaciones de red, integración de sistemas, servicios
administrados, diseño y arquitectura de infraestructura y preventa técnica. Actualmente es parte de la unidad de
negocios de Gestión de Infraestructura y Servicios de Seguridad en Happiest Minds Technologies Pvt Ltd. Es
PÁGINA 2 1
responsable de la estrategia de práctica de infraestructura, soluciones y desarrollo de oferta, preventa y equipos de

habilitación de entrega. Girish tiene amplios intereses en la nube, centros de datos, redes y tecnologías
emergentes.
MBCTG
www.mbctg.com
MBCTGMBCTG se especializa en la modernización de TI. Diseñamos, desarrollamos e implementamos productos de última generación en
los campos de la infraestructura de software (middleware, data stores, almacenamiento y analítica) e Iaas (Infraestructura como servicio)
orientada a Internet, SaaS (Software como servicio) y PaaS (Plataforma como servicio) aplicaciones.
Explíqueme algunos de los errores más grandes que ve que las empresas cometen en la forma en que abordan el problema de
llevar la TI a un enfoque DevOps moderno.
DevOps con un presupuesto
Las empresas intentan destacarse frente a la competencia con menos recursos y personas menos capacitadas, lo que conduce a la mala calidad
entregada. DevOps es bueno solo con los recursos y la experiencia adecuados. Además, DevOps une a los desarrolladores, el control de calidad y la
seguridad, por lo que una administración inadecuada no es asequible.
Enfoque desalineado
Las herramientas son los elementos que permiten DevOps, quitando algo de trabajo manual, eliminando la repetición de procesos y administrando de manera efectiva los
recursos disponibles. Pero el valor real de las herramientas está en los objetivos que las personas alcanzan con su uso.
Equipos de DevOps separados
La creación de un equipo DevOps independiente generalmente agrega procesos y complejidad. También es difícil obligar a los equipos de operaciones
y de TI a colaborar. Las empresas deberían centrarse mejor en el proceso DevOps en lugar de en una nueva unidad porque DevOps es solo un nuevo
enfoque para desarrollar productos más rápido.
Esperando magia
DevOps no se va a administrar solo. Se trata de aprendizaje continuo y PEQUEÑAS mejoras CONTINUAS. Las empresas necesitan
profesionales para gestionar los recursos, los presupuestos, las metas y el progreso, priorizar y dividir los proyectos en plazos más cortos,
y los hitos son la clave para obtener resultados en la fase inicial.
No prepararse para el cambio de cultura

PÁGINA 2 2
El cambio es parte del proceso de DevOps y es inevitable. La mayoría de la gente no se adapta al cambio y continúa con patrones
familiares, especialmente cuando el cambio es difícil.

La nube es un tema candente en este momento, pero muchas organizaciones carecen de la experiencia para saber cómo abordarlo. ¿Cuáles
son algunas de las preguntas que las organizaciones deberían hacerse a medida que comienzan a construir una estrategia para integrar una
solución que les funcione?
¿Cómo influye la computación en la nube en nuestra estrategia y arquitectura de aplicaciones?
¿Cómo accederemos, protegeremos, gestionaremos, integraremos y gobernaremos en todos los entornos de nube? ¿Cómo deberían
cambiar nuestro centro de datos, enfoques de infraestructura y tecnologías existentes?
¿Cómo deberían las empresas evaluar una línea de base para lo que necesitan de su infraestructura en la nube?
Los gerentes deben comprender el rol comercial que la nube asumirá en su negocio. Cloud no se diferencia de ningún otro servicio subcontratado,
como la recepción o la contabilidad. A veces, la nube simplemente no es la solución adecuada para la empresa. La línea de base sería definir el
proceso de negocio o un rol que necesita el negocio. Luego para descubrir cómo implementarlo. Por ejemplo, una empresa que busque aplicar un
desarrollo basado en pruebas tendrá una línea de base diferente a la de una empresa que busque el rendimiento de las aplicaciones o las soluciones
de facturación y contabilidad en la nube.
Hablas de la idea de una "transformación en la nube". ¿Cuál es el enfoque más exitoso que ha visto adoptar a las organizaciones para
garantizar que el cambio a la nube proporcione todas las funciones y los beneficios anticipados al tiempo que minimiza la
interrupción de las operaciones comerciales durante la transición?
Identifique una razón comercial específica para migrar a la nube: comprenda la motivación, los resultados comerciales, los cambios
comerciales y el alcance del proyecto.
Desarrolle un caso de negocio para migrar a la nube.
Diseñe, planifique y cree una estructura básica de cuentas en la nube (cómo administrar las cuentas en la nube) y entornos de control
(respaldo, redes, IAM y DR) que respalden las necesidades centrales de negocios, seguridad y cumplimiento.
1. Analice sus antecedentes y objetivos. Revise las fuentes de datos y las cargas de trabajo actuales.
2. Revise el seguimiento actual. Descubra tendencias, comportamientos atípicos y rendimiento general.

PÁGINA 2 3
¿Cuáles son algunos de los problemas que enfrentan las empresas cuando intentan configurar una nube híbrida y cómo pueden
resolverlos?
Las empresas deben resolver muchos problemas para que sus estrategias de TI híbridas funcionen. Los sistemas heredados, múltiples cargas de trabajo, encontrar y
volver a capacitar a las personas adecuadas, la seguridad y los problemas de cumplimiento se encuentran entre los
principales desafíos que TI debe mitigar. Hoy en día, la mayoría de las empresas terminan con la nube híbrida por accidente. Las
empresas están integrando la nube pública con tecnología local sin estandarizar. Nosotros
vea más “experimentos” en la nube de TI en la sombra que de repente se convierten en producción y prácticas de gobierno obsoletas que ponen a una
empresa en alto riesgo. Para diseñar una buena estrategia híbrida, las empresas deben considerar la estandarización de la infraestructura como práctica de
código. El esfuerzo por ser un híbrido es tanto cartular como tecnológico. Las empresas deben adaptar tanto el soporte local como la automatización de CI /
CD. Capacite a la fuerza laboral en el desarrollo de infraestructura como código. Y cree equipos funcionales centrados en la entrega de productos.
Hablemos de escalado. ¿Cómo pueden las empresas escalar de manera efectiva su infraestructura de nube pública, privada o
híbrida mientras se aseguran de encontrar el equilibrio óptimo entre costos e ingresos?
La ampliación o ampliación vertical se realiza cambiando el tamaño de su servidor sin cambios en su código. El escalado horizontal o el escalado
horizontal están agregando nodos adicionales a la infraestructura existente. Puede combinar la implementación de estrategias de escalado esenciales:
tiempo y umbral. La sincronización es una estrategia simple que se escala hacia arriba o hacia abajo vertical y horizontalmente según la hora
programada, como eliminar una instancia a las 19:00, que es eficiente para cargas de trabajo periódicas. Un umbral es la estrategia más popular
cuando el escalado se decide por el umbral dado: memoria, uso de CPU, ancho de banda y otras métricas de la aplicación. Por supuesto, también
puede utilizar una estrategia mixta.
Una de las principales razones para escalar es aumentar el rendimiento. La arquitectura escalable puede manejar ráfagas de tráfico y cargas de trabajo
pesadas. Sin embargo, a veces, en caso de pasar de un monolito a microservicios, el escalado puede aumentar el tiempo de respuesta, que también es
una de las principales métricas de rendimiento. La eficiencia de la escalabilidad generalmente depende de la granularidad de los recursos y de los
diferentes tipos y patrones de carga de trabajo máxima.
Las empresas a veces saben que deberían escalar, pero temen la cantidad de tiempo que lleva. ¿Cuál es la mejor manera para que las
organizaciones escalen rápidamente?
La escalabilidad es la nueva norma. El escalado automático le permite crear una infraestructura consistente y un escalado basado en aplicaciones para
controlar los costos. Implica combinar el seguimiento y la integración de planes de acción. La mayoría de los proveedores de la nube proporcionan (porque les
interesa ampliar el consumo de recursos) herramientas integradas y hacen que sea relativamente fácil lograr el escalado. Un enfoque más eficaz sería utilizar
plataformas de servicios de corretaje en la nube como Abiquo. El producto Abiquo permitirá a las empresas implementar de manera rápida y eficiente el
escalado multicloud y mantener el control del presupuesto del proyecto. El escalado de múltiples nubes o el estallido de la nube es un mejor enfoque y
beneficiará a su empresa al mantenerse fuera de la trampa del proveedor.

PÁGINA 2 4
El escalado de múltiples nubes correctamente configurado puede detectar e informar cuando se requiere escalar, ser prescriptivo sobre qué escalar y orquestar
todos los procesos subyacentes a través de la automatización. Y de nuevo, tenga cuidado con el bloqueo del proveedor.
Además de la escala, la infraestructura como servicio (IaaS) ofrece muchas promesas y muchos peligros en términos de seguridad.
¿Qué vulnerabilidades cree que pasan por alto las empresas? ¿Qué proceso pueden seguir para minimizar el número de descuidos?
En general, IaaS es vulnerable a todas las amenazas que conocemos de los entornos locales. Como inyecciones de SQL, secuencias de comandos entre sitios y
otros ataques conocidos enumerados en el Proyecto de seguridad de aplicaciones web abiertas (OWASP). Por lo tanto, las aplicaciones deben desarrollarse
teniendo en cuenta las prácticas de codificación segura.
Según Gartner, los riesgos de seguridad en la nube de IaaS más comunes siguen siendo la mala configuración y las llamadas cargas de trabajo de “TI en la sombra”,
como servidores de prueba implementados y no actualizados, almacenamiento huérfano y recursos de red. La mayoría de estos problemas se abordan mediante la
creación de procedimientos de TI correctos, el uso de automatización y mecanismos de supervisión.
¿Puede compartir una solución creativa de gestión personalizada que haya visto que otras organizaciones podrían
inspirarse?
Muchos clientes con los que trabajamos han estado buscando traer un nuevo producto o servicio al mercado. Para lograr ese objetivo,
necesitará una solución que tenga una arquitectura simple e implementada sin afectar sus inversiones existentes en infraestructura.
También necesitará una solución que utilice pilas de tecnología conocidas, por lo que no necesita perder tiempo capacitando a su
equipo técnico y tiene la flexibilidad para integrarse a su tecnología y procesos existentes. Complicar demasiado cualquiera de estos
solo aumentará el tiempo que tomará lanzar su nuevo servicio y, en última instancia, le costará caro. Elegir una solución como Abiquo como
plataforma de gestión de la nube le permitirá alcanzar sus objetivos rápidamente. Abiquo se basa en una pila de tecnología familiar con una
arquitectura modular simple que permitirá que su negocio escale cuando lo necesite. Tenemos un historial de implementación rápida y
podemos trabajar con usted para que su proyecto sea un éxito.
Si solo pudiera compartir una de las mejores prácticas de infraestructura de nube de TI, ¿cuál sería?
Será una completa pérdida de tiempo crear un nuevo servicio si no puede venderlo. Pero con demasiada frecuencia se ha pensado
muy poco en responder esta pregunta hasta que se ha creado la solución y no ha sido utilizada por clientes. Es fundamental
comprometerse con sus clientes existentes lo antes posible en este proceso. Después de todo, no podrá responder algunas de las
preguntas anteriores si no comprende lo que necesitan sus clientes. Es igualmente importante interactuar con su equipo de ventas.
Son los que habitualmente están frente al cliente y deberán comprender lo que necesitan vender. También es esencial asegurarse de
construir algo que puedan vender.
PÁGINA 2 5
Maxim Borovkov
CEO
Ejecutivo emprendedor e inversor con más de diez años de experiencia en la gestión de
soluciones basadas en la nube y seguridad informática.
compañías. MBCTG se estableció en el año 2009 como una firma de servicios profesionales y de consultoría de middleware. Hoy brindamos
excelentes servicios profesionales enfocados en la mejora del rendimiento, la arquitectura y la estabilidad de las aplicaciones. MBCTG agrega
servicios de desarrollo e integración y revende productos de software y hardware innovadores.
Nuestra misión es acelerar el éxito de nuestros valiosos clientes a través de los procesos de modernización y transformación de la nube.
PÁGINA 2 6
Nuestro equipo está formado por personas talentosas, experimentadas y altamente capacitadas con honestidad, integridad, profesionalismo y
capacidades comprobadas en la ejecución de proyectos de tecnologías avanzadas.
Contáctenos
Oficina de Cleveland: info@mbtg.com Oficina de Tel Aviv: info@mbtechgroup.co.il

QBurst
www.qburst.com
Una empresa global de consultoría y desarrollo de productos con un fuerte enfoque en plataformas tecnológicas de
nueva generación. Brindamos una amplia gama de servicios en torno a Analytics, AI / ML, Desarrollo web y móvil,
DevOps, Diseño de experiencia de usuario, Blockchain, IoT y Testing.
Su sitio web indica que parte de su misión principal es "ayudar a los clientes a maximizar el
efectividad de su negocio ”. ¿Cuáles son algunas de las formas comunes en las que considera que la falta de adopción de DevOps
perjudica a las empresas? ¿Existe algún drenaje recurrente en la productividad que las empresas ni siquiera conozcan?
Algunos problemas comunes que hemos encontrado son:
• Ciclos de implementación lentos, que a menudo retrasan varios cambios pequeños por semanas durante una ventana.
• Los problemas tardan más en solucionarse.
• Mucha incertidumbre y coacción antes del lanzamiento de nuevas funciones.

• La fase de implementación / despliegue a menudo se ignora al realizar estimaciones para implementar una nueva solución.
• Los cambios de configuración menores a menudo se pasan por alto y no se aplican en los servidores.
• Los equipos de operaciones suelen revertir los cambios durante un incidente, sin comprender si ese cambio realmente causó el
problema.
En entornos que no son DevOps, los equipos dedican mucho tiempo a resolver problemas una y otra vez. Esto no solo conduce a la insatisfacción,
sino que también genera una pérdida significativa de productividad.
¿Cómo sugeriría a las empresas que evalúen sus propias necesidades de DevOps?
Una buena forma de evaluar las necesidades de DevOps es tener un enfoque de abajo hacia arriba en el que los equipos se evalúen a sí mismos y
encuentren áreas para mejorar en función de los objetivos de la empresa. Considere si los equipos están unificados, son extensos o trabajan en silos.
¿Existe un clima de transparencia?

PÁGINA 2 7
• Evaluar el estado actual de Dev y Ops

• Compruebe si los equipos pueden colaborar y equiparse con las tecnologías y prácticas de los procesos de los demás.
• Análisis de brechas: identificar oportunidades para la automatización
• Identificar desafíos en la gestión de versiones, implementaciones y compilaciones

• Evalúe la capacidad de su organización para entregar y mantener aplicaciones estables para satisfacer los requisitos comerciales tan
rápido como se necesitan.
• Examinar si existen procesos formales de gestión de servicios de TI y si estos son lo suficientemente maduros
Una de las grandes barreras para la adopción de DevOps es el miedo que surge de la gran cantidad de plataformas divergentes
utilizadas por los equipos de Desarrollo y Operaciones. ¿Cuáles son algunas de las preguntas que las empresas deberían responder
internamente al crear un plan para garantizar transferencias rápidas y fluidas entre equipos que utilizan herramientas divergentes?
• ¿Cuál es el nivel de habilidad y conocimiento del equipo actual?

• ¿El equipo está abierto a aprender y adaptarse a las nuevas tecnologías?
• ¿Cuánta capacitación se requiere para garantizar una colaboración interfuncional sin problemas?
• ¿Cuál es la viabilidad de utilizar un conjunto común de herramientas en toda la organización?
• ¿Cómo se pueden reducir las transferencias individuales?
• ¿Qué experimentos seguros para fallar se pueden realizar para identificar áreas que necesitan atención?
¿Por dónde deberían empezar las empresas a automatizar su proceso iterativo? ¿Cómo se aseguran de que su nueva
automatización no interrumpa tanto sus procesos manuales actuales que la productividad se vea afectada a corto plazo?
Idealmente, cualquier tarea repetitiva debería automatizarse. Y como tal, todas las instalaciones, cambios de configuración e implementaciones deben
automatizarse y, cuando sea posible, el aprovisionamiento de servidores debe automatizarse.
Empiece por automatizar las tareas que no consumen mucho tiempo pero que son repetitivas. Puede ser una tarea sencilla, como instalar un servidor web en una
máquina o implementar un archivo war en un servidor.
Para asegurarse de que la nueva automatización no interrumpa los cambios existentes, comience probándola en entornos inferiores como Dev / QA /
Stage. Inicialmente habrá mucha reescritura involucrada, pero a medida que los equipos se adapten y comiencen a crear scripts de automatización, se
puede ahorrar mucho tiempo con la automatización de tareas repetitivas.
Sobre el tema de la organización entre equipos, hable sobre algunos de los problemas de control de versiones que ven las empresas con
procesos manuales. ¿Puede dar un ejemplo de cómo DevOps puede optimizar las solicitudes de cambio y la recuperación ante desastres?
PÁGINA 2 8
Uno de los problemas clave con algunos de los sistemas de control de versiones es la ineficiencia en el servicio a equipos dispersos geográficamente. La
escalabilidad de los sistemas de VC también es un punto débil que está afectando el éxito de DevOps.
Las herramientas de control de versiones y (lo que es más importante) una buena estrategia de control de versiones ofrecen muchas ventajas, pero las principales en este
escenario son:
• Una forma sencilla de ver qué ha cambiado y cuándo

• Una sola fuente de verdad
Con una buena estrategia de bifurcación, cada solicitud de extracción proporciona una forma sencilla y fácil de comprender lo que implica
la fusión. Al adjuntar un PR a cada solicitud de cambio, resulta sencillo comprender qué se publica con el cambio.
Un ejemplo de cómo DevOps puede agilizar las solicitudes de cambio y la recuperación ante desastres: para un plan de recuperación ante desastres simple, como copia
de seguridad y restauración, el uso de una herramienta de VC para Infraestructura como código ofrece una única fuente de verdad que define cómo debería verse cada
instancia. Lo mismo se puede utilizar para realizar una DR, siempre que se haga una copia de seguridad de los datos relevantes, para que se pueda restaurar. Además,
el uso de Configuration Management ayudará aún más al garantizar que los paquetes y dependencias requeridos se implementen en todos los ámbitos.
Hablemos de contenedores. ¿Cuáles son algunos de los problemas comunes que ve que enfrentan las empresas con tecnologías
como Docker y cómo se pueden superar?
a. Vacilación para adoptar algo nuevo y no comprender adecuadamente cómo funciona el contenedor o cómo
los valores incorrectos donde no es necesario. Por ejemplo, usar ARG en lugar de ENV, o usar enlaces donde están en desuso. Todos
estos se pueden abordar fácilmente mediante programas de formación.
si. No pensar en la orquestación de contenedores o en cómo se deben implementar los contenedores en producción y
política de implementación para el mismo. Avanzar hacia una canalización de CD definida ayuda, al igual que definir el ciclo de vida de una aplicación.
Las empresas que se trasladan a los microservicios suelen necesitar mantener intactos algunos de sus monolitos heredados. ¿Cuáles son
algunas de las mejores prácticas que puede ofrecer sobre cómo utilizar DevOps para aprovechar al máximo una aplicación híbrida monolítica /
microservicio?
La solución recomendada es tener una velocidad dual para DevOps en configuraciones híbridas, donde la práctica es tomar las cosas con calma
con monolitos y moverse rápido con microservicios, aunque esto no siempre es posible. A menudo se recomienda implementar la mayor cantidad
de prácticas de DevOps en todos los entornos de manera uniforme. Sí, esto se puede evitar para mantener el entorno estable, pero solo
ralentizará el ritmo en su conjunto.
PÁGINA 2 9
Siempre que sea posible, también se sugiere comenzar a buscar la migración de sus aplicaciones heredadas a su nuevo entorno, o al menos
comenzar a reestructurar su código. La solución que se adapte al cliente dependerá de las necesidades del cliente.
La seguridad del servidor es un gran problema en este momento. ¿Cuáles son algunas de las estrategias que sugiere que adopten las empresas para
garantizar que las aplicaciones permanezcan estables para los usuarios finales?
Cuando hablamos de seguridad en el mundo de DevOps, por lo general nos referimos a la seguridad de las aplicaciones (y todo el cambio de práctica) o la
seguridad del servidor. Para todos nuestros clientes, sugerimos una política estándar cuando se trata de proteger los servidores. Para los clientes que no
tienen preferencia, sugerimos CIS (https: //www.cisecurity. Org / cis-benchmarks /) como mínimo. Por lo general, hacemos esto configurando libros de
jugadas o roles dentro de la herramienta de administración de configuración para configurar todos los estándares en el entorno. Tenemos este libro de
jugadas / rol ejecutado como el primer paso (y obligatorio) contra todos los servidores. Además, sugerimos ejecutar el mismo en intervalos de rutina para:
a. Detecta desviaciones de configuración y resuélvelas.
si. Agregue nuevos estándares a las políticas cuando se publiquen
La deriva de la configuración del servidor a menudo se considera una realidad inevitable de las organizaciones empresariales
complejas. ¿Qué mejores prácticas puede ofrecer a las empresas sobre cómo mantener el rendimiento de sus aplicaciones?
El escenario ideal es utilizar una herramienta de gestión de configuración automatizada, por ejemplo, Puppet, que tiene un agente que se ejecuta
siempre y garantiza que no haya ninguna deriva de configuración. Sin embargo, eso no siempre es posible. Por lo general, sugerimos una de dos
cosas con respecto a la Gestión de la configuración (CM):
a. Realice auditorías periódicas en todos los dispositivos para capturar y corregir los cambios de configuración
si. Configure un monitor automatizado para ejecutar rutinariamente lo mismo, basado en un agente (similar a cómo Puppet
lo hace) y corrige automáticamente las desviaciones.
Desde una perspectiva de proceso, sugerimos que todos los cambios se envíen al repositorio que aloja su herramienta de administración de
configuración. Entonces, incluso si está realizando un cambio de parche crítico en producción, debe agregar ese cambio a su CM. Si no
puede confirmar los cambios de antemano, debido a la gravedad del problema, al menos debe agregarse lo antes posible después.
Si pudiera ofrecer una mejor práctica a las empresas que actualmente utilizan algunos principios de DevOps pero
que quisieran aumentar la adopción, ¿cuál sería?
Adopte iterativamente: identifique una aplicación piloto, forme un equipo de DevOps multifuncional que incluya desarrolladores, probadores y
PÁGINA 3 0
operaciones. Examine sus posibles limitaciones y cuellos de botella y cree una canalización de implementación que aborde estas limitaciones
de proceso. Mide el progreso, el éxito y repite.
Pasar a DevOps implica cambios en la estructura, actitud y herramientas del equipo. El enfoque debe estar en permitir que las
organizaciones se adapten culturalmente y automaticen procesos clave en desarrollo, pruebas, integración, entrega y monitoreo.
Resuma la misión y los métodos de QBurst. ¿Existe una historia de cliente que represente el valor que les brinda a sus
clientes de DevOps?
Nuestro cliente es pionero en análisis basados en la nube. Su producto permite a las empresas integrar fácilmente dispositivos habilitados para Internet con
sistemas comerciales. Mediante una serie de procesos, los datos se organizan en formatos consumibles que pueden utilizar los sistemas posteriores. QBurst
trabajó con el cliente en el rol de DevOps, lo que les permitió controlar los cambios en los repositorios maestros de productos, implementarlos en una gama más
amplia de entornos y obtener un acceso más amplio para ayudar a las operaciones a diagnosticar problemas de producción. Puede consultar el estudio de caso
aquí.
Praven John es un arquitecto de DevOps en QBurst con 11 años de

experiencia como DevOps, ingeniero de nube y administrador de sistemas.
Un gran defensor de los sistemas de código abierto, Praven pasa su tiempo
libre con la familia, los libros y persigue con entusiasmo su interés por la
fotografía.
Contáctenos
Estados Unidos Hechos rápidos

• Más de 120 clientes activos en todo el mundo que confían en nuestras soluciones
comerciales y de consultoría en todas las industrias.
14150 Newbrook Drive
Suite 115, Chantilly, VA 20151 • Más de 1400 proyectos implementados con éxito
+ 1-571-281-2720 • Alianzas y asociaciones clave: Microsoft Gold Partner, Salesforce

info@qburst.com Registered Consulting Partner, Oracle Gold Partner, Adobe
PÁGINA 3 1
Enterprise Solutions Partner, Amazon Web Services, Salesforce

www.qburst.com
Registered Partner, Drupal OrganizationMember
• Principales clientes: NYU, Dell, Bajaj Allianz, Bozutto, Omron, AddThis,

Petrofac, Adani
ReleaseTEAM
www.releaseteam.com
ReleaseTEAM es una empresa de consultoría DevOps de servicio completo de propiedad de veteranos, que presta servicios
tanto al sector público como al comercial. Nos enfocamos en ayudar a nuestros clientes a adoptar y madurar su metodología de
ciclo de vida de desarrollo de software, con soluciones adaptadas a sus objetivos y cultura. Ofrecemos las mejores soluciones
de la industria, entregadas con más de 20 años de experiencia. Ofrecemos consultoría DevOps, soporte, aumento de personal,
tutoría y soluciones de software DevOps. Nuestro personal trabajará con usted para comprender sus necesidades únicas,
auditar su proceso de desarrollo actual y recomendar rutas de adopción con el mayor rendimiento. Luego, nuestros consultores
evalúan las herramientas y son dueños de la implementación.
Escribiste una publicación de blog sobre la importancia de las herramientas DevOps. ¿Qué consejo puede dar a las empresas sobre cómo evaluar
eficazmente sus necesidades y seleccionar las herramientas adecuadas para satisfacerlas?
La selección de herramientas es fundamental, pero como ha señalado a menudo nuestro blog, no más que las personas y los procesos. El conjunto de
herramientas adecuado es exclusivo de cada equipo u organización; deben adaptarse a sus procesos y personas. Muchas organizaciones cometen el error de
intentar cambiar a su gente y sus procesos para que se ajusten a las herramientas. Considere el panorama completo, investigue y deberían surgir las opciones
correctas. Por supuesto, contratar a un consultor experimentado para que lo ayude a evaluar su entorno y seleccionar las mejores herramientas nunca es una
mala idea.
Utiliza el potencial del "infierno de la integración" como una razón para garantizar la calidad de los procesos de Integración Continua. ¿Qué puntos
de referencia objetivos pueden utilizar las empresas para identificar cuándo se encuentran en el infierno de la integración? ¿Cuál es el primer paso
que dan para intentar salir de eso?
Puede resultar obvio para muchos cuando tienen problemas de integración. Aún así, muchas organizaciones se acostumbran tanto a dejar tiempo en un
cronograma para las integraciones que se vuelven insensibles; ya están en el infierno de la integración. El punto de referencia objetivo es que las integraciones
están tomando tiempo durante la programación del producto. El primer mejor paso es implementar CI.
PÁGINA 3 2
Escribió un documento técnico completo sobre cómo implementar DevOps en un entorno resistente a los cambios.
¿Cuál dirías que es la mejor comida para llevar?
El cambio hace que la mayoría de las personas se sientan incómodas hasta cierto punto, especialmente cuando se trata de hacer su trabajo. Para facilitar
el proceso a su equipo, manténgalos informados y sintiendo que son parte del proceso y no se apresure a implementar todos los cambios a la vez.
Demasiados cambios a la vez pueden ser abrumadores y hacer que algunas personas sientan que se están quedando atrás. Dejado y dejado atrás, a
nadie le gustan esos sentimientos.
Ofrece a las organizaciones la oportunidad de "capacitar a sus instructores [DevOps]". ¿Cuál crees que cometen los gerentes
de error número uno encargados de instituir principios de DevOps en su equipo?
La capacitación para un nuevo proceso o herramienta debe comenzar antes de que la nueva tecnología esté en producción. Es fundamental asegurarse de que
todos estén en la misma página y sepan lo que deben hacer para sobresalir en sus trabajos. El hecho de que los miembros del equipo trabajen codo con codo
con un profesional experimentado durante la implementación de su nuevo entorno agrega una capa adicional de conocimiento que luego se puede compartir con
el resto de su grupo.
También ofrece capacitación DevOps personalizada para equipos. Eso subraya un énfasis en la cultura tanto como en la destreza
técnica. ¿Cómo deben influir las consideraciones culturales en las decisiones estratégicas que toma la dirección al implementar
DevOps?
Cuando una organización ignora la cultura de su entorno, los nuevos conceptos no tienden a quedarse. Por ejemplo, puede enseñar la
política Zero Blame a todos en su organización, pero el concepto no logrará ganar terreno si los equipos o individuos continúan
identificando las causas fundamentales de los errores en un individuo u otro grupo.
¿Cuáles son algunos de los mayores desafíos de seguridad de DevOps que las empresas enfrentan hoy en día y a dónde deberían acudir
para comenzar a abordarlos?
La seguridad siempre ha sido una preocupación para el desarrollo de software; DevOps permite a los equipos abordar los problemas de forma más rápida y temprana en el
proceso. Hay muchas herramientas de seguridad excelentes que las organizaciones deberían explorar para abordar sus necesidades de seguridad específicas; sin embargo, la
seguridad comienza con las personas y las mejores prácticas. La formación adecuada y el acceso a las políticas y procedimientos de seguridad son fundamentales.
En el lado de la TI, ¿cómo deberían las empresas equilibrar los beneficios de la infraestructura como código para la escalabilidad con el
PÁGINA 3 3
creciente potencial de desviación de la configuración que viene con la escala?
IaC es una tecnología fantástica, y las organizaciones que utilizan DevOps también deberían adoptarla. Sin embargo, IaC encaja con muchas otras grandes
tecnologías que pueden, junto con los principios de DevOps, mejorar la repetibilidad, el tiempo
al mercado y la productividad general. Es como la mantequilla de maní y el chocolate: ambos se sostienen por sí solos pero también son geniales
juntos.
Menciona la necesidad de trabajar con planes de reversión como parte de la gestión de versiones. ¿Qué tipo de cosas deberían hacer las
empresas para asegurarse de que puedan retroceder rápidamente cuando sea necesario?
La recuperación ante desastres ha sido una parte fundamental de los sistemas desde sus inicios. Tener acceso a versiones anteriores (y con suerte estables) de
software y archivos garantiza que pueda, bueno… recuperarse de un desastre. Por supuesto, DevOps nos brinda automatización. Tener planes de reversión
automatizados es un gran comienzo. Agregue una estrategia sólida para administrar las implementaciones, como las rutas de implementación azul y verde, y las
implementaciones canarias, para eliminar el tiempo de inactividad y minimizar el impacto de los problemas, de modo que no se conviertan en desastres.
También escribió una publicación de blog sobre los desafíos de seguridad de DevOps que enfrenta el sector gubernamental. ¿Cuáles son algunas de las
mejores prácticas para que las entidades gubernamentales equilibren la velocidad del tiempo de entrega con las necesidades de seguridad?
Aproveche la automatización en todas partes y lleve la seguridad a las canalizaciones de productos. Incluyendo todo el alcance operativo dentro de una tubería, la
seguridad se convierte en una parte integral. Con este enfoque, las agencias gubernamentales pueden utilizar DevOps para abordar los problemas de seguridad en
el ciclo de creación y lanzamiento del código.
Si pudiera brindar a las organizaciones un único consejo de DevOps que tenga un impacto inmediato en su
organización, ¿cuál sería?
Si estamos limitados a una sola pieza, entonces comprenda su valor. El conocimiento es poder. Evalúe, aprenda, enseñe y documente.
PÁGINA 3 4
Shawn D. Doyle
Co-Fundador, CEO
Shawn D. Doyle es fundador y director ejecutivo de ReleaseTEAM, Inc., una empresa consultora de DevOps, establecida en
1999. Después de servir en el ejército de los EE. UU. Y Desert Storm, ha acumulado casi 30 años de experiencia en la entrega de software,
habiendo trabajado con empresas de tamaño mediano a Fortune 100 para resolver sus desafíos críticos para el negocio. Shawn vive con su
esposa y tres perros en Colorado, donde está trabajando en su primer libro, DevOps Overture: What you need to know when start a DevOps
Journey.
Contáctenos
Sede corporativa Massachusetts Canadá

PÁGINA 3 5
1400W122nd Ave. 1257 Worcester Rd. PMB # 604

Suite 202 Suite 108 1-110 Cumberland St.
Denver, CO 80234 Framingham, MA 01701 Toronto, ONM5R 3V5
(866) 887-0489
info@releaseteam.com
RocketMakers
www.rocketmakers.com
RocketMakers logra mucho como equipo pequeño. ¿Qué consejo puede dar a los pequeños equipos de DevOps sobre
cómo superar su peso y lograr el mayor impacto posible con solo unas pocas personas?
Reemplace la documentación con scripts (que se autodescriban tanto como sea posible).
Modularice los componentes tanto como sea posible: mantenga cada parte del flujo de trabajo lo más simple y repetible posible. Concéntrese en algunas
buenas herramientas y manténgalo constante.
Su sitio web menciona la idea de "desarrollo ágil rápido y fallido". ¿Cuál es el mayor error que tienen
las empresas sobre lo que eso significa y cómo lograrlo?
Fallar rápido tiene que ver más con el negocio que con la tecnología. Para nosotros, es la forma en que podemos demostrar que los clientes necesitan el producto para
resolver un problema genuino lo más rápido posible, lo que a menudo se denomina ajuste de producto / mercado en estos días. Después de haber construido muchas
startups, la parte más difícil es cerrarlas cuando se quedan sin efectivo / tiempo, por lo que nos gusta fallar rápidamente (si van a fallar) para que podamos seguir
aplicando los aprendizajes de esa falla al Próxima oportunidad.
En ocasiones, las empresas sienten que deben comprometer la seguridad y la velocidad. ¿Cuál es la verdadera naturaleza de la relación
entre estos dos objetivos? ¿Cómo puede la administración minimizar la exposición al riesgo sin aumentar los plazos de entrega?
Por lo general, vemos que la seguridad y la experiencia del usuario están más en desacuerdo que la seguridad frente a la velocidad. Por lo general, la seguridad se interpone
en el camino del viaje del usuario sin problemas y tenemos que comprometernos en alguna parte.
Dicho esto, algunas cosas clave para nosotros son:
• Tener código / scripts repetibles que hayan sido probados y reutilizados puede ayudar
• Hacer las cosas bien y rápido no siempre se excluyen mutuamente: los componentes y microservicios que se han probado, probado y se pueden reutilizar
son la forma en que aceleramos la puesta en marcha y mantenemos los costos bajos.
• La educación es clave: asegurarse de que los desarrolladores y DevOps comprendan las posibles vulnerabilidades de seguridad y cómo se pueden mitigar.
PÁGINA 3 6
• La coherencia en la arquitectura es esencial: insistimos en tener scripts probados en su lugar que muestren todo el entorno de una manera
completamente probada. De esa manera, obtiene entornos repetibles y predecibles que ahorran tiempo a largo plazo y también ayudan con la
recuperación ante desastres.

Manteniendo el tema de la seguridad, DevSecOps es otra palabra de moda que escuchamos mucho ahora. ¿Cuál es una forma concreta
para que las empresas piensen en los conceptos incluidos en ese término y cómo pueden incorporarlos a sus estrategias de DevOps?
Hacer bien los conceptos básicos, como hacer que no haya secretos en la fuente, garantizar que las claves se administren de manera efectiva fuera del
control del código fuente en bóvedas, etc.
Minimice conscientemente la exposición / área de superficie de la aplicación y las herramientas que usa para construir e implementar
Eliminar el acceso directo: restringir el acceso a quienes realmente lo necesitan, bloquear las máquinas virtuales y los contenedores a las conexiones controladas
y considerar el uso de un enfoque de bastión para conectarse.
Realice pruebas de penetración regulares idealmente a través de un tercero y actúe según sus recomendaciones
Utilice siempre el principio de privilegio mínimo con todas las aplicaciones, contenedores y máquinas que se ejecutan con el mínimo de permisos de
forma predeterminada y aflójelos solo para necesidades documentadas específicas
Trabajas con startups. ¿Estas organizaciones más pequeñas necesitan DevOps? ¿Cómo se ve la implementación en comparación con lo
que se necesita en una estructura corporativa más grande y madura?
¡Seguro! Desafortunadamente, a menudo no ven el valor (cuando a menudo quieren cada dólar gastado en funciones), pero lo
necesitan. La buena noticia es que lo hacemos por ellos y les informamos sobre el retorno real de la inversión a largo plazo.
Sin falta, todos ven el valor más adelante, cuando podemos crear un entorno con solo tocar un botón para demostrar una nueva característica y
cuando encontramos problemas de rendimiento, disponibilidad, escalabilidad, etc.
Para nosotros, necesitan lo mismo que una organización más madura si van a escalar, por lo que lo abordamos desde el sprint cero.
A medida que las empresas crecen, mantener la estabilidad mientras escalan es un gran desafío. ¿Cómo puede DevOps ayudar en este proceso y
cuáles son algunas de las mejores prácticas para escalar las operaciones y la cultura de DevOps?
Tal vez hemos tenido suerte, pero desarrollar un conocimiento y una capacidad centrales de DevOps desde el primer día significa que esto no es un problema en
PÁGINA 3 7
nuestra experiencia.
Tener procesos repetibles y consistentes es esencial y aquí es donde trabajar con un taller de desarrollo que ha pasado por todo esto antes
puede marcar la diferencia: nos tomó al menos 18 meses hacer que nuestros procesos iniciales funcionaran y una década de ajustarlos
desde entonces. .
Si bien muchas personas buscan documentación, nuestra opinión es que la autodocumentación evita malentendidos, documentos antiguos, etc. Sin
sugerir que tener documentación sea malo de ninguna manera, solo que la documentación desactualizada puede ser peor que nada en absoluto.
También pensamos que un conjunto de herramientas común = lenguaje común = entendimiento y eficiencias comunes.
Si tuvieras que elegir la única trampa que ves con más frecuencia que las organizaciones de escalamiento tienen con DevOps, ¿cuál
sería? ¿Qué pueden hacer las empresas para evitar el mismo problema?
No configurar todo de manera consistente al principio con miras a escalar desde el primer día sería la clave de nuestra experiencia. Para ayudar a
evitarlo, asegúrese de programar para sentar las bases de DevOps en Sprint Zero y aprovechar los conjuntos de herramientas existentes en lugar de
escribir el suyo propio.
Trabaja con todas las integraciones de DevOps más populares, pero, por supuesto, cada organización tiene sus propias necesidades. ¿Cómo
deben evaluar las empresas las herramientas de DevOps para poder encontrar la pila que mejor se adapte a sus necesidades?
Eso es muy individual, así que establezca sus propios objetivos / resultados y concéntrese en asegurarse de que se cumplan en lugar de preocuparse por los detalles. En
nuestro caso, nos preocupamos por hacer la vida más fácil a los desarrolladores y equipos de operaciones, independientes del proveedor, autodescriptivos, coherentes
utilizando herramientas y tecnología probadas, y usando un enfoque de compra en lugar de compilación cuando sea posible, pero con nuestro propio código para orquestar
según sea necesario.
Si pudiera brindar una mejor práctica a las empresas que buscan escalar o revisar sus operaciones de
DevOps, ¿cuál sería?
Ven a RocketMasters :-)

Más en serio, concéntrese en la contenedorización a través de Docker o similar y la administración a través de Kubernetes, etc. y asegúrese de tener
entornos que se puedan crear y ejecutar de manera local y remota de manera coherente.
Si pudiera dar una práctica a las empresas que se preparan para implementar DevOps por primera vez, ¿cuál sería?
¡Aprenda Docker y Kubernetes rápidamente!

PÁGINA 3 8
ScienceSoft
www.scnsoft.com
scnsoft.com/services/devops-consulting
Uno de los puntos débiles que intenta aliviar es la “falta de colaboración horizontal eficiente”. ¿Cuáles son algunos de los
errores de colaboración que ve que las empresas cometen una y otra vez? ¿Qué mejores prácticas puede ofrecerles para
aliviarlos?
El único error de colaboración que, en nuestra opinión, puede tener un impacto mayor y más negativo en los procesos de trabajo es la distribución
poco clara de roles y responsabilidades. Cuando incluso una persona del equipo no sabe lo que debe hacer y lo que están haciendo sus
compañeros de trabajo, todo el equipo corre el riesgo de enfrentarse a consecuencias desagradables: varias personas pueden realizar las mismas
tareas, mientras que otras no. t realizado por nadie en absoluto. Es primordial asegurarse de que todos estén en la misma página en términos de su
alcance de trabajo propio y colectivo.
Hablas de ayudar a los clientes a desarrollar una “nueva agenda tecnológica”. ¿Qué quieres decir con eso?
En lugar de simplemente enumerar las posibles mejoras tecnológicas, creamos una 'agenda' detallada y equilibrada, un plan que ayuda a
una empresa a ver claramente los pasos graduales que deben tomarse para mejorar su estrategia de TI actual. También empleamos la
gestión del cambio para que la transformación sea lo más sencilla posible para los negocios del cliente. Como resultado, nuestro enfoque
ayuda al cliente a asignar convenientemente sus inversiones y reduce las posibles pérdidas financieras relacionadas con la interrupción del
proceso comercial durante el cambio de estrategia.
Su sitio web indica que los departamentos de TI deberían pensar en lo que hace que una empresa esté "centrada en el
cliente". ¿Cuáles son los grandes objetivos estratégicos que las empresas deberían buscar lograr para lograr un enfoque
de TI centrado en el cliente?
Creemos que la interacción empresa-cliente debe organizarse de una manera que minimice los esfuerzos por parte del cliente. Las empresas de TI
deben esforzarse por facilitar la comunicación atendiendo a los antecedentes de la industria del cliente y la profundidad de su comprensión de los
aspectos específicos de TI. La capacidad de explicar todo en términos sencillos es uno de nuestros principios fundamentales que hace que nuestros
servicios se centren en el cliente.

PÁGINA 3 9
Enumera la “reducción del gasto en TI” como objetivo de su consultoría de TI. ¿Cómo pueden las empresas lograr eso, manteniendo /
aumentando la calidad de sus servicios a los usuarios finales?
Antes de lanzar cualquier cooperación, discutimos el alcance de la consultoría con nuestros clientes para establecer objetivos claros y
definir expectativas de nuestros servicios. En nuestra práctica, esto no solo conduce a la
satisfacción con la calidad de nuestros servicios, pero también evita que su presupuesto exceda.
Trabaja con configuraciones de nube híbrida. ¿Cuáles son algunos de los errores clave que ve que las empresas cometen una
y otra vez al configurar estos sistemas híbridos?
Los errores comunes están relacionados con la elección y combinación de nubes públicas y en el sitio. Los clientes pueden concentrarse demasiado en los costos
y optar por una nube pública con una velocidad de rendimiento más baja mientras tienen una nube en el sitio muy rápida. Esta diferencia a menudo resulta en un
rendimiento asombroso en general.
Cuando se trata de datos y métricas, su sitio web indica que ayuda a las empresas a "desarrollar reglas y políticas para garantizar una alta
calidad de los datos". ¿Cuáles son algunas consideraciones clave para las empresas si desean realizar su propia auditoría interna de sus
políticas de datos?
Durante la auditoría, nos aseguramos de que las políticas de datos corporativos regulen al menos dos aspectos más importantes: la calidad y la seguridad de
los datos. Las políticas de gestión de la calidad de los datos deben cubrir los atributos a rastrear (es decir, coherencia, integridad, precisión), reglas que
permitan verificar si una entrada de datos corresponde a un determinado atributo (es decir, 'El nombre completo del cliente debe incluir al menos un espacio') y
umbrales (es decir, el 85% de todos los registros de datos deben cumplir). Con la combinación correcta de herramientas de gestión de la calidad de los datos,
es posible automatizar la mayor parte del proceso de evaluación de la calidad de los datos y monitorear continuamente el status quo por atributo. En cuanto a
la seguridad de los datos, las empresas deben realizar evaluaciones de vulnerabilidad y pruebas de penetración mensuales al menos una vez al año para
introducir los cambios necesarios y reconsiderar las políticas existentes.
Andy Lipnitski
Director de TI en ScienceSoft con 8 años de experiencia en servicios de TI
gestionados. Andy tiene una amplia experiencia en diseño de arquitectura

PÁGINA 4 0
de soluciones y
despliegue. Dirige la entrega efectiva de consultoría e implementación de infraestructura de TI, servicios de

infraestructura gestionada y servicios de soporte, servicios en la nube (AWS, Azure, etc.) y migración a la
nube, Consultoría DevOps y diseño e implementación de tuberías de CI / CD.
Aprende más
Las herramientas de Inedo facilitan DevOps
BuildMaster es una herramienta de CI / CD de primera clase que automatiza las compilaciones, las pruebas y las versiones, y garantiza el cumplimiento de las
puertas y los permisos, todo con un panel unificado para una visibilidad de un extremo a otro.
ProGet mantiene su repositorio seguro y las entregas confiables mediante la autogestión de paquetes y la administración de cargas para maximizar el tiempo de
actividad.
Otter lo ayuda a evitar el dolor de los errores imprevistos y difíciles de corregir causados por cambios indocumentados en el servidor al monitorear la
desviación de la configuración e informar sobre la corrección necesaria.
¿Quiere saber más sobre los

productos de Inedo?
CONÉCTESE CON NOSOTROS PARA MÁS DETALLES:
Mike Goulis
Director de Operaciones
mgoulis@inedo.com
PÁGINA 4 1
56 Front Street., Berea, OH, EE. UU. 44017
https://www.inedo.com/
(440) 243-6737
@inedo
https://www.linkedin.com/company/inedo

DevOps Best Practices 2020 Full Guide Final - En.es PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

DevOps Best Practices 2020 Full Guide Final - En.es PDF

Cargado por

Copyright:

Formatos disponibles

DevOps

EMPRESAS QUE CONFIAN EN INEDO AXIAN 4

TECNOLOGÍAS DE MENTES MÁS FELICES 18

alta calidad a los lectores.

las métricas adecuadas y la adopción de los aspectos culturales de DevOps.

Empresas que confían en Inedo

entorno de integración continua (CI).

software actual es adecuado para satisfacer sus necesidades?

en sus prácticas de DevOps que falte o necesite mejorarse.

Al migrar a la nube, las organizaciones deben considerar varios factores clave.

C. Gastos personales de mantenimiento continuo

aprovechar al máximo la utilidad de su nueva infraestructura?

único de una organización?

cuenta para evitar dolores de cabeza en el futuro?

esta visión en un documento. Crea metas que se adhieran a

continuación (aproximadamente en este orden):

1. Mata tu ego y estima a los demás más grandes que a ti mismo

7. Identifica tu límites de servicio

13. Comprometerse con el proceso de desvinculación de sus servicios

1. "Capacite" a los equipos ejecutivos sobre DevOps

3. Empoderar a los equipos para trazar su propio rumbo

facilitar más automatización

6. Construye tus equipos parecerse a pequeñas organizaciones de software

2. Menos miedo a realizar cambios significativos

3. Entregue valor a los clientes en menos tiempo

4. Aumente la productividad del desarrollador

5. Mejora de la comunicación entre equipos

6. Mayor cohesión de los empleados

7. Alineación, enfoque y visión corporativos

Mark Johnson es un arquitecto de soluciones que trabaja con una variedad

problemas comerciales desafiantes. Él cree que es necesario un enfoque integral

de DevOps para crear soluciones de software que sean escalables y puedan

evolucionar con las necesidades comerciales. PÁGINA 9

Desacoplamiento, Arquitectura y Equipos

negocio y la tecnología comenzaron a funcionar como uno.

• Estrategia: trabajar al revés desde el cliente

La transición del estado actual al estado futuro se ilustra a continuación:

capacitados para lograr el objetivo de la empresa.

compartirán los riesgos y se adoptarán las novedades.

para que sus equipos prosperen.

asegurarse de que no se conviertan en una limitación para la adopción?

(Ries), Radical Candor

Yo diría que los puntos ciegos clave incluyen:

• el liderazgo querrá que la organización cambie y no se considere a sí mismo

Personas e interacciones sobre procesos y herramientas - Manifiesto ágil.

comprensión, practicar, dominar, automatizar.

particularmente importantes para lograr ese objetivo?

capacidades necesarias para competir y ganar en este mercado vibrante.

conmigo mismo hace 4 años:

1. Esto va a tomar algunos años, ¡abróchate el cinturón!

2. Va a empeorar antes de mejorar, ¡ten fe!

6. Conviértete en el evangelista de la organización, lee, aprende, comparte, aplica, repite

7. Afronte los problemas difíciles de frente, hombre arriba.

8. No tengas miedo, ten coraje, sé valiente

da como resultado la transformación de "meses" en "minutos".

Cardiff Londres 0800 368 7378

Tecnologías de las mentes más felices

en cuenta las empresas al ejecutar una nube híbrida?

mejores prácticas se destacan a continuación:

Monitoreo de TI unificado Habilitación de desarrolladores

• Descubrimiento profundo para la asignación de • Integración DevSecOps

• Monitoreo inteligente de infraestructura y aplicaciones • SDLC seguro

recursos Informes y análisis