The DevOps Factors
The developer of this repository has not created any items for sale yet. Need a bug fixed? Help with integration? A different license? Create a request here:
Methodology for building proper DevOps culture
Priorities for Ops and Dev teams should be the same. One managed for both teams improving culture as well. This combination allows you to implement error budget and reduce the overhead of communication between teams. Priority item is the most important and cannot be changed (and not depends on the implementation).
Ops is responsible for stability, and Dev for features
Communication is very important. Communication is the foundation of DevOps. Your Soft skills are necessary and often more important than the technical background. Coming to a new company, you will most likely have to promote culture, break stereotypes and often meet poor engagement people in the near-DevOps sphere.
constantly sit in the headphones, and work only on your part of the system
The concept of Infrastructure as Code is fundamental to the DevOps methodology. IaC is important and necessary in order to recover from an incident, with a minimum of effort to move to another platform, versioned changes for transparency of management, the convenience of working on infrastructure in a team, and the ability to roll back to a previous state. Also, the infrastructure must be tested qualitatively, according to the principles of the testing pyramid (unit, integration, system tests).
manual undocumented changes
A good DevOps team should have full interchangeability, a flat structure and mutual assistance. If you have several products or dedicated parts of the system in your company, it is necessary to periodically take tasks not from your main specialization to expand your horizons and cultivate interchangeability. A good DevOps team should look like a complete system - all team members can complete the task that has arrived.
assign team members to a product or part of a system
A strong knowledge gap, even within the same team, always entails problems. A completely different expertise in people on different components of the platform will always lower the team’s performance and complicate the prediction of delivery. The presence of unique skills in one engineer makes him indispensable and sooner or later he turns into a living point of failure. Therefore, it is necessary to pre-determine gaps and their criticality in advance, quickly eliminate them by exchanging experience and information. High-quality documentation and transparency of the development process greatly simplifies this process.
to file alone the tool, in the code and use of which only its creator can figure out, leave it without documentation and quit. share high priority tasks without asking for the opinions of your teammates and not share the results of its implementation.
DevOps team must predict problems, not just put out fires.
CI is a process describes the sequence of steps for building an application. Artifact must be created as result of the CI process. An artifact is a compiled application, ready for further delivery. The CI process with the testing pyramid gives confidence in the artifact, and guarantees that the assembled application will definitely work. In this case, we gain confidence in the changes, and it becomes possible to deliver value to users more often.
do not test the application
implement artifact delivery in scope of the CI process
CD describes a process for delivering an artifact. The basic concept is to unify this process for all environments. There are different delivery strategies: blue / green, canary, and others. In most cases smaller changes delivered have less probability to break production environment. Value delivery must always be in working state and deliver value to customers upon the first business request. The next future of Continious Delivery is Continious Deployment.
manual deployment to the environment by checklist
The main feature of DevOps methodology is continuous iterative improvement. It's not necessary to theoretically design the most fault-tolerant and stable system with ideal processes for an infinite amount of time - on the contrary, cyclically introduce improvements and receive fast feedback. In this case, it will be possible to design a platform that will meet most of your requirements in a minimum amount of time. In the process of development of the platform must be a constant professional growth.
for a long time, to the smallest details, think through the nuances of the system design, but do not implement anything
If something went wrong with your production - you need to fix it first. And only when the system came to a stable working condition, you can begin to understand what's happened and how to prevent it in the future. As a rule, after notification of an incident, the support engineer quickly evaluates the problem and problem components, gathers people with this area of responsibility and manages the recovery process. According to the results, it is necessary to describe the incident in the bug tracker, conduct a retrospective and make the decisions necessary to prevent it in the future.
find out why the system does not work, instead of online recovery
write documentation on how to repair, instead of preventing globally
A good DevOps team should have a fuzzy development plan for the next 3-6 months with the main global goal that reach business values. There is no point in creating detailed plan and describe the technical implementation - it is very likely that the team will depart from it at certain points and change the tactics of achieving the global goal.
clearly and thoroughly outline the development plan for the next 10 years
There are a huge number of tools to solve each individual problem, and you need to choose the right tool for the job as correctly as possible and not chase the fashion trends that are constantly appearing. This is rational for solving problems of low and medium levels. In the case of the design architectural solutions it is worth paying attention to modern practices and approaches. As a result, this will indirectly save time and money on remodeling and implementing “bicycle”. There are two good rules here: 'plan before execute' and 'code wins arguments' (in the sense that it is better to try and compare several solutions on your own tasks than blindly grab the tools from Github)
a new beta version of the framework X is released, tomorrow we’ll move