My company removed developers' production access because they were suggesting quick fixes based on incomplete evidence—for example, seeing high CPU usage and recommending a service restart. The downside is that developers can no longer inspect live logs, so DevOps has to manually forward log data whenever customers report a problem.
My manager now wants the DevOps team to learn enough of the application's business logic to debug issues independently, then provide developers with evidence and a proposed solution instead of just sending logs. Is this a normal expectation? How much application logic should DevOps understand, and who should be responsible for finding the root cause of production problems?
3 Answers
DevOps should understand the application well enough to deploy it, operate it, recognize abnormal behavior, and narrow down incidents. That does not mean the platform team should become the owner of every business-logic defect or duplicate the developers’ role.
A healthy model is shared ownership: developers help operate and debug what they build, while DevOps provides the platform, observability, guardrails, and operational expertise. If production access was removed for security or compliance reasons, replace it with audited read-only access rather than making DevOps the only group that can see what is happening.
The usual solution is not to remove visibility—it’s to remove write access. Give developers read-only access to centralized logs, metrics, traces, dashboards, and relevant infrastructure data. Tools such as a log aggregation platform and metrics dashboards let them investigate customer issues without SSH access or the ability to restart services.
DevOps should make the evidence easy to obtain, but the application team should generally investigate bugs in its own business logic. High CPU is a useful symptom, not automatically the root cause. You want request IDs, structured logs, traces, error rates, latency percentiles, database metrics, and similar signals so everyone can test hypotheses instead of guessing.
If developers need someone to forward screenshots or log excerpts, the organization has created a bottleneck. A searchable, audited read-only portal is a much better compromise.
The team’s poor troubleshooting is a training and process problem, not a reason to hide production evidence. Teach people to distinguish symptoms from causes, require evidence for proposed changes, and prevent unsafe actions with permissions and a break-glass process.
For production, developers should normally have no direct write capability, but they should be able to inspect logs, traces, metrics, and perhaps read-only configuration. Operational fixes should be automated or performed through controlled, audited workflows. The goal is to remove barriers between teams while preserving safety—not to recreate a wall where DevOps becomes a log-delivery service.
In larger organizations there may be a separate SRE or operations function, but even then it usually produces a well-supported incident report and collaborates with the application team rather than owning every code fix.