Ask HN: What could developers do to help the Ops Team?
I'm researching about DevOps and what the dev team can do to improve the Ops Team efficiency/productivity? I already have some feedbacks of local teams, however I would like to listen what is your pain.
22 comments
[ 3.3 ms ] story [ 70.9 ms ] threadBut, this isn't always the case, so here's something a dev can do:
- Know basic server administration. Nothing too crazy:
- Be the master of your dev environment. If the organization uses virtualization for everything, learn how to manage those virtual machines, or at least, know where to find the config files and where to find the documentation in-case you need to change the config files. Read through the config files so you at least feel confident navigating them.- Know what happens when code is deployed. Where does it go? Which servers? How to log into those servers to debug issues? Where are the logs? Ask what you'd need to know if you were suddenly put in-charge of the the project as the sole-developer-webmaster type person.
I think if a developer is able to do the above, then their devops team will think more of them and maybe be more willing to help when things aren't working out.
Also, improving production performance/scalability.
And making apps simple to deploy. That's about it for me :)
Just things like not requiring complex set up steps and wiring up many different services with complicated configurations etc. Keeping things stateless (as much as possible) etc
> Also, do you talking about to stop CI/CD flow? Why not to provide a way to keep that flow on production?
Not sure what you mean, but slow tests can be a major problem. Most of the time these end up being due to no thought going in to not repeating the same setup steps zillions of times. As new tests are constantly added, it makes it harder and harder to keep builds/ci fast.
"How develop/maintain a complex software and at same time keep it simple to set up without a huge bottleneck with Ops team"
If state(ful) is a problem, How about KILL Stateful? Maybe we need to (re)think about how we are handle with microservices? If true, that's is an good hypothesis to validate in a dev perspective.
Don't rush new features or code into production. Don't deploy anything after 5pm on a Friday.
Documentation, documentation, documentation. If there's a piece of knowledge for your app that's only in your head, you have failed.
I know that I will add a layer of abstraction, however from a Dev perspective I have some benefit like a byte-to-byte compatible test/prod env that I haven't to worry about dependencies per example.
[1].:http://dl.acm.org/citation.cfm?id=2593813
Understand why certain security procedures are put in place even though they do create some friction.
We've caught issues ranging from expired passwords, missing files / files with incorrect permissions / write failures, sync issues and other obscure gotchas.
Catching a failed step during deployment can sometimes prevent a huge rollback effort and save a lot of time.
Good tests, with good code coverage.
Work with us when we suggest to you that we deploy to a non-production environment first.
Work with us to automate as much as we possibly can.