Changing Behavior for DevOps Culture

Compartilhar no facebook
Compartilhar no linkedin
Compartilhar no twitter
Compartilhar no whatsapp

At a time when the term DevOps is increasing each day and increasingly attracting the attention of companies and major players in the industry, due to the reduction in time to market, better product quality and higher revenue, we see below some principles of how to present a DevOps culture and not focus solely on the automation aspect.

Some of the main common pillars of companies with a true view of DevOps:

  • System thinking: end-to-end vision of the system, from the business idea to the technological implementation, breaking paradigms of functions of developers and ops.
  • Focus Flow: translates business ideas into a job service efficiently by examining how fast the artifacts and work flow through the development lifecycle.
  • Increase the importance of feedback: learn quickly about the system by observing through quick feedback on what happens to the results of changes through constant approvals and tests.
  • Continuous improvement and constant learning: This part is not a cliché. The teams from the trainee to the director must learn to constantly adapt and understand that there is no end point in a delivery, but rather the consummation of all previous points which is an attitude of continuous improvement and placement of constant feedback loops for a good product continuously.

Exemplifying a set of practices and initiatives that successful DevOps organizations incorporate into their daily way of working to achieve the four pillars above:

  1. Delete the word “done / delivered”, services are never completed, they are continuously running and must be serviced continuously
  2. Treat operational requirements as first-class points to give them impact visibility as they pass through the same pipeline as the functional requirements
  3. Visualize the workflow so everyone is aware of what is happening everywhere and the critical points become visible. Everyone in every team know what’s going on? I doubt it!
  4. Collaboratively map the value stream to understand the complete image of the system and highlight the waste of time and resources.
  5. Turn information flows into artifact flows by reducing the transfer of ambiguous information and clarifying the interactions that people need. It’s no use saying to a newcomer on the team: “turn around”, that’s what leaders are for, to guide.
  6. Combine relevant data into meaningful metrics that provide situational awareness to different stakeholders in the organization, especially for startups investors.
  7. Bring awareness of changes, correlating them to metrics and presenting them in graphs
  8. Show the value of teams, convey the mindset of awareness, make everyone feel part of the overall system
  9. Decentralize control and align responsibility with the developers / support / infrastructure / POs / etc, of the artifacts (eg, Dev responsible for the uptime of your code, Ops responsible for platform uptime, etc.)
  10. Run internal mini-conferences where everyone can align what is being done, what can be done and feel empowered to make changes
  11. Joint deployment checks for each service provided by the development team with the help of the operations team and others to avoid problems thrown on the wall
  12. Stop the workflow (introducing more changes) when problems arise and focus on finding the actual bottleneck source and fix it in a definite way
  13. Ensure transparency with the client, assume when things go wrong, or when someone does not have the specific knowledge in the team
Comentários do Facebook

Conteúdos relacionados