Hacker News Reader

Comment by lostcolony | Hacker News Reader

So one of the requirements for SOX compliance is that no one person can unilaterally push code to prod. While there is all manner of wiggle room to how this is implemented , what it means for many risk averse companies who want to be certain to be in compliance is dev and ops are kept separate (and ops may be labeled 'devops' because they seek to build automated processes for deployments, rather than manual deploys).

But, yes, the original idea behind devops is that separation is nonsensical. It's just been misconstrued at many places to mean that we need more dev-y people in the ops role, rather than it's the same role.

View on HN

> one of the requirements for SOX compliance is that no one person can unilaterally push code to prod.

I don’t believe that’s part of the SOX regulation, which for the most part says you must define your management controls, including your segregation of duties policy, and also have processes to audit that those controls are followed, but I believe is silent on the specifics of what that policy must contain with respect to one person releasing code to prod, particularly code which does not impact financial reporting. (Your company controls may have adopted such a rule, of course, which make them a SOX requirement for you.)

You’re correct; you essentially write your own rules for SOX compliance. SOX audits are to check that you comply with those rules. There’s a lot of wiggle room, and I suspect many hire a consultant that has a general framework of rules you “should” have to get through the initial certification.

Separation of Duties is very, very much part of SOX regulation. While it may not explicitly say "One person can not both author a change, and push it to prod, with no one else involved", if that's allowed and pointed out to any auditor, you are going to fail the audit.

So, yes, you are technically correct (the best kind of correct!), but in any applicable sense, it is indeed a requirement. As I called out, there is loads of wiggle room on how to address it (technically you probably are in compliance if you just force PR approvals, but I'm not that familiar with the actual verbage, and am definitely not a lawyer), just that the risk aversion of most companies (and the intransigence of auditors) sees those who write the code (dev) and those who deploy the code (ops) being separated quite frequently in order to be SOX compliant.

If your controls say you can do that, you will not fail the audit. The audit for SOX is a compliance-with-controls audit.

Consider the jobs board for your company, the documentation site, or some other unrelated to financials, but production tech nonetheless. You can write your controls to say that someone can push an update without separating duties.

Just as we do for PCI, one key to making SOX sensible is to keep as many systems out of scope of the strictest controls, by sensible design choices (in tech and in policy) and be strict where strictness is sensible and more free when that freedom is more sensible.

SOX is only concerned with accuracy of financials and while it’s bad law in several key regards IMO, it seeks to accomplish this mostly via transparency and compliance with elected policy rather than specifically prescribing the policy contents.

Many internal functions run on Excel sheets using “we save copies very carefully on shared drives” revision control. When those get changed, there might not be one person who knows everything that changed, let alone two.

> So one of the requirements for SOX compliance is that no one person can unilaterally push code to prod. [...] many risk averse companies who want to be certain to be in compliance is dev and ops are kept separate

Here's an example of compliance setting a user back for no real benefit.

I'm in an organization that did this separation before we were forced to put our socks on. What we realized is that only a dev can usefully check a dev. Gating of code into prod needs to be by a dev, and the gating of infra changes needs to be gated by ops people. But that individuals, and the role, are best as combined as dev+ops.

So we implemented the separation, but not by splitting our worked into two separate groups and putting a wall between. We had other teams so we moved the review inter-team. I develop, maintain, and manage my piece of my team's service, but also do release-review for pieces of an entirely separate project that I have no access to other than to read the code.

That seems a lot better to me. Also, I don't know anything about SOX compliance, but couldn't you have another dev on the same team do a review? Or is there a part of it about the reviewer needing to be without context or something of that sort?

I feel it’s less a “code must be reviewed” and more a “you need two keys to arm the nuclear warhead” type of thought.

You can have another dev on the same team do a review

In the meantime in Google we do have dev and SRE... And for bits in scope of SOX a separate Release Engineering org. Go figure.

Even better, there's dev and SRE, and within SRE there's SRE-SWEs and SRE-SEs. Truly management word salad.

> and ops may be labeled 'devops' because they seek to build automated processes for deployments, rather than manual deploys

Ok, but that just seems like one of those useless definition switcheroos no?

In that world, what has changed from before? When dev and ops were seperate, and dev and ops are still seperate?

Your definition of DevOps is correct as far as I've seen it in theory and in practice. If you have a separation of dev and ops and you still try to say you use devops then you are probably just playing the buzzword game.

Reply on news.ycombinator.com