Blaming or punishing when mistakes are made is apriori a disastrous approach. This culture of pointing out a guilty person produces hostility among the coworkers and they will be focused more on shifting the blame away from themselves rather than on doing their jobs well. Another problem in this approach is the opinion that human beings can't make a mistake, especially if it is a senior specialist.
Moreover, search for "black sheep in the family" will lead to Anti-pattern #4: the individuals will be concentrated only on their piece of job, without dipping into the business. What, in its turn, will consequently lead to building silos between teams.
Same old silos, meaning the acquired mentality when team members don't want or can't share information, their knowledge. Role segregation and blameful culture are a consequence of the silos, which, in its turn, lead to decrease in efficiency.
For instance, an average siloed climate within the teams: they use absolutely incompatible tools to complete similar tasks, the team members don't have a straight access to the decision makers or those possessing the needed information. Thus, the lack of information leads to endless downtimes and technical debt.
To avoid this, each DevOps adoption pattern begins with breaking the silos and establishment of the normal communication between ALL teams, not only between Devs and Ops. That's why, when hiring the companies providing DevOps as a Service
, it's worthwhile to begin with business processes analysis and estimation of how teams communicate between each other.