AIOps and SECI address different parts of DevOps work: AI and machine learning can help handle recurring operational signals, while knowledge-sharing practices help people transfer context across development and operations. Their combination is a useful design idea, but the available evidence does not establish that human knowledge is the main DevOps bottleneck or that combining the two improves outcomes. “Human bottleneck” is the framing of the motivating article, not a measured causal finding.
What AIOps means in a DevOps context
AIOps applies artificial intelligence and machine learning to systems and operational work. Microsoft Research describes three AIOps pillars: AI for systems, AI for customers, and AI for DevOps. In its research framing, AI for DevOps aims to bring AI and machine learning into the software development lifecycle to increase productivity. That describes a research direction; it is not evidence that a particular tool or implementation has achieved a specific productivity gain.
AIOps is not one standardized product or fixed feature set. In the proposed DevOps relationship, its clearest role is assisting with repeatable work where operational signals are machine-readable and prior patterns are useful—for example, surfacing or interpreting recurring events. Novel incidents, ambiguous signals, and decisions dependent on organizational context still require people to review, escalate, and apply judgment.
Why knowledge sharing is a separate DevOps concern
The DevOps Knowledge Sharing Framework is a design-research framework built on the SECI model. Its summary specifically includes knowledge conversion between development and operations. That makes knowledge exchange part of how delivery work is organized, not merely a question of which documentation tool a team uses.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →#1 Best Overall
In this article, SECI is best treated as a framework for thinking about how knowledge is shared and converted, including knowledge that is difficult to reduce to written instructions. The available framework summary does not provide a complete canonical definition of all four SECI modes, so it would be misleading to present a detailed account of each mode as though that source established it.
This distinction matters when a team needs to transfer situational understanding: why a service behaves unusually, which past incident resembles the current one, or when an established procedure is unsafe to follow. Such context may be held by people and exchanged through discussion and reflection rather than already existing as a searchable, machine-readable signal.
Rank #2
How AIOps and SECI can complement each other
A practical synthesis—not a tested comparison—is to use automation for recurring, data-rich operational patterns and SECI-informed practices to help teams surface, articulate, combine, and learn from context. AIOps can help make signals and known patterns easier to interpret; knowledge-sharing practices can help people connect those signals to experience across teams and carry lessons into future work.
| Dimension | AIOps role | SECI-informed knowledge-sharing role |
|---|---|---|
| Primary task | Support repeatable operational signal handling and pattern recognition. | Structure knowledge conversion and learning between development and operations. |
| Knowledge involved | Machine-readable events and patterns that can be recognized from available data. | Contextual or tacit knowledge that may require interaction and interpretation. |
| Human contribution | Review results, escalate exceptions, and make judgments when a case is novel or ambiguous. | Participate in knowledge sharing, explanation, and reflection. |
| Evidence status | Microsoft Research describes research pillars and aims; that description is not an outcome evaluation. | The framework establishes a SECI-informed design, while related empirical evidence remains exploratory and qualitative. |
The distinction is not “machines versus people.” Automation may make relevant operational information more visible, while people help interpret meaning and transfer lessons that are not captured by the available data. The sources support this as a conceptual fit, not as proof that the combined approach reduces incident rates, delivery time, or workload.
What the evidence says—and what it does not
Early qualitative evidence on GenAI and SECI
A 2026 exploratory study examined knowledge creation through the SECI lens using semi-structured interviews with 22 software engineers who regularly use generative AI. Its authors describe both enabling and constraining effects across knowledge-conversion modes and note the generalizability limits typical of qualitative research. The study is relevant to how AI may affect knowledge work in software engineering, but it is not a controlled evaluation of AIOps combined with SECI in DevOps.
AI’s boundary around tacit knowledge
A systematic review summary indicates that AI can support aspects of knowledge creation and sharing, while human interaction remains important to socialization because AI lacks social skills and contextual sensitivity. The review also identifies limited research specifically on AI’s contribution to tacit knowledge. This is a reason not to assume that knowledge can be automated end to end.
Rank #4
The “human bottleneck” remains a thesis, not a measured result
The motivating DZone article proposes AIOps for “known knowns” and SECI to democratize “known unknowns.” Those phrases offer a conceptual way to distinguish recurring patterns from less settled knowledge, but the reviewed sources provide no operational benchmark validating the combined approach. They do not quantify how often human knowledge is the limiting factor, nor show causally that AIOps plus SECI solves it.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How a DevOps team could evaluate the idea locally
A team considering this approach can turn the thesis into testable questions. Establish a baseline, define a consistent measurement period, and compare like-for-like services or incidents before and after a specific change. The following are proposed local measures, not published impact findings:
Best Value
- Recurring incident share: What proportion of incidents match patterns the team has previously documented or observed?
- Time to find relevant prior knowledge: How long does it take responders to locate a useful runbook, incident record, or knowledgeable colleague?
- Escalation to named experts: How often does resolution depend on reaching a particular person, and how long does that handoff take?
- Repeat incidents: How often does a previously encountered failure recur, using a consistent definition of “repeat”?
- Post-incident learning reuse: Are lessons from reviews incorporated into runbooks, operating practices, or later decisions?
Interpret these measures together. For example, faster retrieval of prior knowledge alone does not show that incidents are resolved more safely, and fewer escalations may reflect better knowledge access—or a change in escalation practice. A credible evaluation should connect any proposed improvement to an explicit measure and account for other changes affecting the service or team.
Quick Recap
When this framing is useful
- Use AIOps as a lens for repeatable operational work supported by usable data, rather than as a claim that all operations can be automated.
- Use SECI-informed knowledge sharing to examine how development and operations exchange context and learn from experience, rather than treating documentation as the whole problem.
- Describe the two as complementary design ideas, and reserve claims about effectiveness for results measured in the team’s own setting or in a directly relevant evaluation.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
