I'm a college intern with mostly theoretical CS experience, and my role has shifted toward DevOps. The team doesn't have much experience with it either. How can I learn enough to tackle pipeline and infrastructure problems without getting overwhelmed?
How do I approach DevOps work when I barely know where to start?
Asked by
3p+windlass_891
Answers
Start with the path from a code change to a running application. Read the existing pipeline configuration and ask what builds, tests, packages, and deploys the software. If any steps are manual, write them down too.
Pick one small bottleneck and work on that rather than trying to redesign everything. A crash course can help with vocabulary, but the team's actual process gives you something concrete to investigate. Before changing it, check how you'll test the change and undo it if needed.
Reply to this answer
Try building a small pipeline in a disposable environment. Have it build and test a simple service, then deploy it somewhere safe. Once that works, introduce a broken build or bad configuration and practice finding the cause.
If the company has a staging environment, ask whether it's suitable for experiments first. Don't deliberately break shared or production systems. The useful part is learning to follow logs, isolate a failure, and recover, not collecting tools for your resume.
Reply to this answer
DevOps covers a ridiculous amount of ground, so don't treat a roadmap as a checklist you have to finish. Learn enough Linux, scripting, networking, access permissions, and secrets handling to understand the task in front of you. Go deeper as those topics come up.
For example, if a deployment can't reach a database, trace the connection and permissions involved instead of jumping straight into a new orchestration tool. Knowing what you don't know is useful here.
6e+gasket_203:
Networking and permissions are especially good areas to revisit when something works locally but fails in the deployment environment.
Reply to this answer
Since nobody on the team has much background in this, make your uncertainty visible. Bring a short proposal that says what problem you're solving, what you plan to change, how you'll check it, and how you'll roll it back. Ask someone responsible for the system to review it before you touch anything sensitive.
Also question advice that sounds like a universal best practice. A pattern may be useful, but find out what problem it solves and whether that problem exists on your team. Simple automation for a repeated task can be a better first project than a big infrastructure overhaul.
Reply to this answer
Add your answer
Answers are reviewed before publication.
b4+switchyard_62:
Even a rough diagram of the current flow can help. Mark the parts you don't understand and investigate those one at a time.