DevOps
DevOps
What is DevOps?
- Breaks down the wall between development and operations
- A culture of fast, reliable releases
- CI/CD as the core practice
What DevOps really changes is not the toolbox but who wakes up when something breaks. In the past, developers stepped away the moment they handed over the code, and operations took the 3 a.m. page. In a DevOps organization, the team that built a feature owns its deployment, monitoring, and incident response from start to finish. So developers add logging from the start, build rollback paths, and plan for traffic spikes. When the people who built it are the ones woken at night, code quality changes.
You judge how well it is working by four numbers, not by feel: deployment frequency, lead time from commit to production, the share of deployments that cause an outage, and time to recover from outages. The moment you put these four numbers on one screen, finger-pointing between teams over accountability shrinks. It also helps to tell the practices apart. CI merges code several times a day and builds and tests it automatically, while CD pushes the result to production with almost no manual handling. Add infrastructure as code (IaC), which manages server and network settings as code instead of documents, and 'it works on my machine' disappears.
It also helps to draw the line against similar terms. If agile shortens the planning and development cycle, DevOps shortens the stretch that delivers the result to customers. SRE is closer to a way of putting DevOps goals into practice through a numeric contract called an error budget, and more companies are now moving toward platform engineering, which bundles pipelines and monitoring into a shared internal foundation that each team can use on its own. With 20 or fewer developers you don't need to go that far; CI and automated tests alone make a noticeable difference.
The most common failure in practice is creating a new 'DevOps team'. You set out to tear down walls, and end up with three silos — development, operations, and DevOps — plus one more deployment-request ticket step. Bolting on deployment automation before you have automated tests is risky too: broken code just reaches customers faster and more often. If three months after installing the tools deployment approval still runs through an email to the department head, you haven't adopted DevOps — you've bought an expensive build server.
Seolyeong ParkGenerative AI and AX training expert with 17 years of hands-on experience and 200+ sessions, making AI usable right away even for non-specialists
Seungtae ParkPractical AX instructor who teaches by building AI business development and marketing automation hands-onIt began around 2009 as a movement for development–operations collaboration, and with the spread of agile and cloud it became the standard culture of software development.
Consider a hypothetical case: Company A, a mid-sized Korean fashion e-commerce company with 320 employees and annual revenue of KRW 140 billion (≈ US$104,743,400). It deployed once a month, at 2 a.m. on a Saturday, taking the service down for four hours. A deployment just before last autumn's promotion triggered a payment error and was rolled back after six hours, and KRW 200 million (≈ US$149,600) in sales was lost that week alone.
- The CTO gathered six development teams and the operations team in one room and spread out a year of deployment records. Four of 12 deployments had been rolled back, and average recovery time was 5 hours 20 minutes. The CTO opened the meeting by saying, 'This is not a skills problem. It is a structure problem.'
- The payments team lead started with the order and payment APIs, which took the most manual effort, and set up automated tests there first. Over six weeks they converted 180 core scenarios into scripts, so every commit now shows a pass/fail result within 12 minutes.
- The infrastructure deputy manager moved server configuration from Word documents into code. Setting up a new server went from two days to 20 minutes, and outages caused by differences between staging and production dropped to zero that quarter.
- Deployment rights went to each team, with one rule attached: 'the team that built it is on call for 48 hours after deployment.' At first there was pushback — 'why us?' — but the fact that alerts now go to their own phones changed how strict code reviews became.
- Six months later, deployments rose from once a month to 11 a week, and average recovery time fell from 5 hours 20 minutes to 34 minutes. Early-morning deployment work disappeared, and night-time call-outs for the operations team dropped from 9 a month to 2.