I assist quite a lot of organizations with their DevOps journey and implementation. Many instances the organizations I work for are massive enterprises or greater firms. Because there are lots of groups inside these organizations which have roughly the identical necessities, there’s typically a so referred to as IT 4 IT division, that’s creating some centralized capabilities.
Although I feel that IT 4 IT just isn’t at all times a superb possibility, as a result of it interjects with the elemental DevOps ideas like autonomous groups, it may make sense if utilized accurately.
When doing DevOps it is essential to do this in a safe approach. Especially in an enterprise that is high of thoughts and the rationale why departments as Change Management, Release Management, Change Architecture Boards and many others. exist. When it comes to safety and enterprise rules, sure issues are required to be in place. Whether it is ISO, SOX , COBIT or no matter different framework is used to validate whether or not you might be compliant, just a few ideas are essential to have in place.
- Ensure integrity by having audit trails on code and artifacts
- Ensure the 4-eyes precept on each change to manufacturing
- Embed Security Testing all through your course of
- Prevent unauthorized (knowledge) entry
Translating these ideas into an implementation typically leads to proscribing entry, shut down performance, denying actions and instantiating management authorities. Because, that’s what we’re used to.
For this function I created the IT4IT DevOps Manifesto. A easy set of ideas that can be utilized in guiding individuals to make the appropriate resolution.
- Protect vs Blame
- Report vs Control
- Enable others vs Doing your self
- Allow vs Deny
- Automated vs Manual
Protect vs Blame
When you implement one thing that leads to an audit path, it routinely turns into seen who did one thing. This blame tradition just isn’t one thing we need to encourage. Therefore, measures should not applied solely to see who has accredited or performed one thing. Implemented measures ought to contribute to larger safety, safety or traceability.
Report vs Control
When you write instruments to stop individuals from doing the fallacious issues, they finally will work round you. And worse, they are going to by no means be taught to the appropriate factor. So instruments that examine if the issues are performed proper, must be in place, however as a validation examine. The report is shipped to the individuals and it’s their accountability to do the appropriate factor. Support, assist and what else will be given however with nice energy come nice accountability
Enable others vs Doing your self
Who doesn’t prefer to be served? Can you create xyz for me or are you able to replace abc? Rights, data, time, right here is at all times a motive why you despatched the work to any person else. But if any person else does our work, it turns into their burden when one thing is fallacious, and so they grow to be your bottleneck once you need to transfer on. So as a substitute of DOING issues for others, we do issues WITH others and ENABLE them to do it themselves by automating or plain instructing
Allow vs Deny
Computer says no! When we take a stand that everyone is doing their greatest, we must always think about permit (or sure) over Deny (no!). A request is granted after which checked as a substitute of the opposite approach round. Most of the issues are allowed in the long run, so why not revert those that weren’t OK within the first place. It is our accountability to examine as a lot as we will in automated trend.
Automated vs Manual
In 9 out of 10 circumstances it’s simpler to do one thing handbook then to do it automated and repeatable. But very quickly you might be able that you’re solely doing handbook work. We automate every part we will. During our automation effort, we will think about to do it manually, however watch out with this!
I hope that it additionally will be of a profit to you!