Three-Layer Skeleton and LLM Governance: The Implementation Ledger and Pitfall Record of a Production-Grade AIOps Platform

This article introduces an AIOps platform developed by our own team.

Let me first clarify its positioning: this is an intelligent operations platform driven by large models. What it does can be summed up in one sentence: it uses AI to connect the three segments in operations that are most prone to breaking, so that the system can both see and act. These three segments are perception, cognition, and action.

Perception is identifying, from massive amounts of telemetry, the signals that truly deserve attention. Cognition is organizing those signals into judgments that are explainable and actionable. And action is actually doing things right within a controlled scope. Beyond these three segments, there is also a cross-cutting governance layer that manages permissions, auditing, observability, and cost. We did not invent this skeleton; it was honed over the past three years through one incident after another.

It is also not a one-page concept diagram, nor something that was declared done once it ran in a demo environment. For some time now, it has been running in our production environment. The engineers on duty use it every day to handle real incidents, and it has carried us through several major outages. The incident record below is one line from our internal postmortem spreadsheet. The number is small, but it is the line I have been most proud of in recent years:

Four minutes and twelve seconds, with only two manual clicks. For similar incidents in the past, it took an average of more than 30 minutes from detection to recovery; if luck was bad and staffing was short on a weekend duty shift, it could drag past an hour. How exactly the time saved in between came about is what I want to discuss in this article. But to explain it clearly, we first need to look at the core designs of this platform. I have picked out a few that I think are most worth discussing and will lay them out first.

As for the modules specifically: the perception layer handles telemetry, topology, alerts, and event streams; the cognition layer handles severity classification, root cause, impact scope, and orchestration; and the action layer handles workflows, scripts, tickets, and self-healing. Cutting across all three layers is the AI governance layer. We set an iron rule for ourselves: every layer both outputs structured results upward and writes auditable records back to the governance layer. In plain terms, every judgment and every action that occurs in the system leaves a trace. This iron rule looks unremarkable, but it later played a significant role in security audits and incident postmortems.

Now, what exactly does the large model do in all this? Many people ask whether bringing large models into operations is just a gimmick. My answer is that it depends on whether they land in specific positions. In our architecture, they do three things:

1. Semantic compression: compress hundreds of MB of fragmented metrics into a root-cause narrative that humans can read.

2. Knowledge retrieval: recall SOPs, runbooks, and historical tickets as context, so skills do not have to cold-start from zero.

3. Decision translation: translate judgments into executable actions.

These three things correspond exactly to the three main threads I will discuss later: the evidence chain, skillification, and gates.

As for how data comes in: the platform connects to more complex things than you might imagine. On the metrics side, it is Prometheus plus Grafana; on the log side, it goes through ELK; on the tracing side, SkyWalking, Zabbix, and several self-developed probes handle proprietary monitoring; and beyond that, CMDB, the release system, and the ticketing system all need to be connected as well, because root-cause analysis can only guess blindly without change records. Once data comes in, it goes through a complete lifecycle: unified collection, normalization, hot/warm/cold tiered storage, and finally consumption by dashboards and alerting. The most expensive part of a self-developed platform is never the model; it is this layer of "data connection" pipelines. It accounts for more than half of the engineering effort in the entire project, yet it is the least visible.

The system's functional modules mainly include the following:

In my view, the most easily underestimated are data governance and reporting and analysis. One does the dirty, heavy work at the very front, and the other does thankless work at the very end. When the project was initiated, both were questioned with "is this really necessary?" because everyone always fixates on the words "AI root-cause analysis," and no one wants to pay for aligning names. This understanding was bought with a pile of pitfalls we stepped into.

In recent years, quite a few friends have asked me the same question: how can large models truly be used in operations? Rather than answering one by one, it is better to write an article. So the content below covers both what we did right and what pitfalls we stepped into. What 47 alerts taught me

The earliest starting point was one early morning.

At 1:40 a.m., my phone, watch, and laptop vibrated at the same time. The P99 latency of the order service shot up from 120 milliseconds to 800 milliseconds. Within five seconds, 47 push notifications flooded in one after another. One from Prometheus, one from Zabbix, one from SkyWalking, and a dozen each from three self-developed probes. I lay in bed swiping through the notifications one by one, and the more I swiped, the more confused I became. Each one looked "correct" on its own, but together they were a disaster. You simply could not tell which one was the root cause and which ones were collateral damage.

Later, when I reviewed that incident, I discovered an even more striking fact: among the 47 alerts, only one truly pointed to the root cause. The other 46 were all "echoes" of the same root cause from different monitoring perspectives. In other words, the density of truly valuable signals that night was 1/47, about 2%. The remaining 98% was noise, adding confusion for the on-duty engineer.

That number later became a benchmark our team kept repeating: the precondition for an on-duty engineer to be willing to open an alert in the middle of the night is that they believe what was pushed to them is worth opening. Once trust is worn away by noise, the alerting system is dead, even if every single push it sends is technically correct.

For a while we made a lot of futile struggles: we tuned thresholds, and alerts decreased but we missed real incidents; we added silence periods, and genuine failures got suppressed; we added aggregation rules, and the rules grew more and more numerous, until no one dared to delete any. Later, a deduplication rule module we wrote ourselves helped us take half a step off the detour: it first converged duplicate alerts with highly similar fingerprints, at least bringing the volume down. But only half a step. In the end we recognized one thing clearly: using manually maintained rules to fight exponentially growing monitoring data is a war that is bound to be lost. What needs to change is not the rules, but the paradigm. Translating alerts into "plain human language": the data foundation and the semantic layer

The first step in changing the paradigm was unexpectedly plain: clean up the data.

Many AIOps projects die at the starting line, not because the algorithms are bad, but because the data is a mess. In Prometheus the service is called aiops-api, in the logs it is called aiopsmicroservice, in Zabbix it is called srv-api-01, and in the CMDB it is simply a different asset number. If you ask any algorithm to perform correlation analysis on data where three names point to the same service, it can only output mysticism.

When I applied to my leader for a quarter to do this, his first reaction was to frown: "A whole quarter, just to align names?" I did not give him a lofty speech. Instead, I pulled out the postmortem records of all P1 incidents from the previous year and showed them to him. The most frequently appearing root cause description in them was not cache penetration, nor connection pool exhaustion, but four words: information not aligned. Monitoring said A, the on-duty person understood it as B, and by the time everyone gathered and got the definitions aligned, the golden handling time was already gone. After reading it, my leader said nothing more and approved it.

We spent almost a quarter doing only one thing: building the semantic layer.

Figure 1: Mapping rule engine. A list of "match condition → mapping target" rules, applied in order of priority.

There was no black magic in the approach, just a mapping rule engine that supports hot updates, versioning, and rollback. The raw alert contains only ip=10.0.1.5, cpu=95%; after translation through the rule chain, it becomes information that operations staff can act on directly:

There is an easily underestimated detail here: rules must be managed like code. Each of our mapping rules has a version number, modifier, and effective time, and if something is changed incorrectly, it can be rolled back to any historical version with one click. Early on, someone once changed a regular expression incorrectly, causing more than 300 alerts that night to be assigned to the wrong team, and we had to apologize in every group chat in the middle of the night. Since then, rule changes going through review and releases going through canary rollout have become iron rules.

How is the canary rollout done? New rules first take effect only on 5% of alerts and run for a full shift; machines compare the classification differences between the old and new rules, and the difference list is manually reviewed once; if there are no problems, it is then released to all traffic. It sounds clumsy, but with something like a rule engine, the cost of an error is global, so the clumsy method is the fastest method. This principle is exactly the same as shipping code, except that many teams forget when working with data that data also needs release discipline.

Incidentally, before writing rules there is also a data exploration module. It was not in our feature plan at all at first; it was a small tool one teammate put together on his own, laying out the field distribution, sample values, and anomaly ratios of raw alerts so you can first understand what the data looks like before you start writing rules. When he first raised this requirement, I even rejected it once, on the grounds that it was the icing on the cake. Later we found that without it, writing rules basically meant guessing field names. I later specifically asked him to add this tool in, and right next to it there is also an information extraction block, responsible for extracting structured fields from large blocks of free-text alert descriptions, for example extracting the data center and rack from a sentence like "link flapping occurred in a certain rack in a certain data center." Such fields are very hard to exhaust with regular expressions alone and need a model as a fallback.

After the semantic layer was built, the second step was where AI finally entered the stage. We fed the alert names, descriptions, sources, and severities to a large model for semantic clustering, then layered on time-window correlation. The effect is obvious at a glance in the interface: 706 alerts from the same day were clustered into 8 root cause clusters, each with a confidence score and the basis for inference.

Figure 2: Alert workbench. On the left is the multi-source alert stream; above is the "AI root cause analysis of the day's alerts" clustering card: 706 alerts were grouped into 8 root cause clusters.

Back to the incident at the beginning: for the same database connection pool accident, the current picture is that the alert event stream aggregates the alerts with the same root cause that night into 1 event, automatically assigns it P1 severity, and automatically dispatches it to the on-duty person. What the on-duty colleague receives in the middle of the night is no longer 47 pushes, but 1 event notification with complete context.

Figure 3: AI assistant conversational troubleshooting. For the sudden latency spike in order-svc, the assistant pulled 42,000 events from three data sources and directly gave the root cause and confidence.

In terms of noise governance, the effective signal density among those 47 alerts that night was only 2%; in similar scenarios today, the alert compression rate has reached 94.2%. This is not a victory of algorithms, but a victory of the combination punch of "data governance + semantic clustering." The evidence chain: teaching AI to reason

Aggregating alerts into events is only the passing line. What truly made frontline colleagues begin to trust the platform is root cause analysis and the evidence chain behind it.

I have to pour a bucket of cold water on this first. The biggest trust barrier for traditional AIOps is the algorithmic black box. The model says the root cause is a database primary-replica switchover, and when you ask it why, it can't answer. An AI judgment that can't explain its basis—even with 95% accuracy—won't be used by frontline staff. Because the fault tolerance for operations decisions is zero; rolling back the wrong version is an incident.

Our solution is to transform the output of root cause analysis from a single conclusion into a traceable evidence chain.

Figure 4: Event detail page. At the top is the AI diagnosis summary card, containing root cause confidence, the number of associated alerts, and priority.

Specifically, the root cause engine strings four types of signals into a causal chain: change records, metric anomalies, log errors, and topology disturbances. The large model performs semantic compression on this chain and outputs candidate root causes and confidence. The key is that every piece of evidence on the chain can be clicked to trace back to the raw data—click in and you see that change ticket, that metric curve, that log line.

When the on-call engineer sees this push notification, what they do is not trust the AI, but verify the AI. So they click open the change record—yes, there really was this release. They click open the metric curve—yes, it really maxed out at that point in time. They click open the log—yes, it really was a connection timeout. Three confirmations in three seconds, then they press the rollback button.

Hidden in this design is a realization we gained from stepping in pits: the value of AI is not in making judgments for people, but in compressing the cost of people making judgments from twenty minutes to three seconds. The evidence chain is for people to read, not for the model. Later we extended this approach to all AI outputs, including event severity classification (why P1 and not P2), impact analysis (why we say these eight thousand-plus users were affected), and postmortem reports—all required to provide clickable evidence.

Event severity classification later gained an additional reference dimension: SLO. We defined availability and latency targets for each core service, and when classifying event severity, we also factor in SLI deviations. So sometimes an alert whose technical metric doesn't look serious gets bumped to P1 because it has already consumed most of the day's error budget. This rule was controversial at first—the business side complained it was too sensitive—until one time it caught a hidden risk that would have violated the monthly SLO in advance, and the controversy subsided.

Of course, the evidence chain wasn't this reliable from the start. We built an evaluation set of several hundred questions, all drawn from real historical incidents, with manually labeled standard root causes, and every change to the root cause engine has to run a regression pass. It was thanks to this evaluation set that we caught a major problem: for "gateway timeout" type faults, the AI's root cause judgment kept guessing cache for three consecutive weeks, and the accuracy for this category was only 40%. Investigation revealed a cause that was both funny and frustrating: the connected signal sources were missing change data from the release system, so the AI couldn't see that "someone changed the gateway config three minutes ago" and could only guess. After connecting the change signal, the accuracy for this type of question jumped directly to over 90%. We talked about this case internally for a long time: when AI guesses wrong, most of the time it's not that the model is bad, but that it didn't see what it should have seen.

By the way, the difference between events and alerts is worth every team thinking through carefully. Alerts are signals; events are the governable objects. We aggregate multiple related alerts into events, classify severity comprehensively based on impact and SLI deviations, and bind the complete lifecycle (trigger, acknowledge, handle, postmortem). The biggest benefit is in the postmortem stage. When an event is closed, all actions by people, bots, and AI on the timeline have already been automatically strung together, and exporting gives you a draft postmortem report. Previously a report took two days to write; now it's ten minutes of editing.

The topology view is the visualized form of the evidence chain. Developers, operations, and business all looking at the same diagram and speaking the same language—the value of this cannot be overstated. The most memorable time was a ticket about an application being slow: the business side insisted it was an operations problem, operations insisted the application was fine, and the back-and-forth dragged on for two days. Then we projected the topology diagram onto the meeting room's big screen, and the traffic path clearly highlighted a slow SQL query in the application itself. Thirty seconds, argument over. Visualization sometimes isn't about making things look better; it's about leaving arguments nowhere to hide.

No matter how good perception and cognition are, if they don't land in action, the value stops at the seeing layer. The action layer is where our internal debates were fiercest and also where we have the most insights.

Some said, rolling back is just clicking a button, let the AI do it. Others said production operations must have human review—if a rollback goes wrong once, who's responsible? The two camps argued in the meeting room for a long time, the whiteboard covered with permutations of autonomy, controllability, and responsibility, and neither could convince the other. There was a young person in our group, the most steadfast member of the "full autonomy camp," whose exact words were, "You're giving the self-driving car a co-pilot and requiring the co-pilot to keep their foot on the brake the whole time." Three months later, it was precisely he who proposed adding a mandatory human review gate for a certain type of operation, because he had postmortemed an external incident case and found that some operations were more irreversible than he had originally estimated. This was probably our most convincing internal shift—not because someone persuaded him, but because he figured it out himself.

In the end, what broke the deadlock wasn't reasoning but an arithmetic problem. We pulled out the past year's operations and classified them, and found that 80% of operations were low-risk and highly repetitive, truly high-risk ones were less than 5%, and almost every high-risk operation had ample context available for judgment beforehand. Since the risk distribution is so uneven, why should the execution strategy be one-size-fits-all? The balance point we finally found was tiered execution:

| Risk Level | Typical Operations | Execution Mode | |---------|---------|---------| | Low risk | Cleaning up logs, restarting a crashed sidecar, disk expansion (with a cap) | AI executes autonomously, notifies afterward | | Medium risk | Scaling, rate limiting, switching to a read-only replica | AI generates a plan, human confirms with one click | | High risk | Rolling back a version, switching core traffic, deleting data | AI only gives suggestions, human operates throughout |

The data after the tiered rollout is quite interesting: 80% of low-risk operations were taken over by AI, the on-call burden dropped visibly, and there have been zero AI misoperation incidents on high-risk operations to date. This balance point wasn't decided on a whim—it was calculated from the probability of incidents.

There's also an unexpected gain worth mentioning. Three months after the tiering mechanism went live, an on-call colleague who had been on the job for just three weeks independently handled a P1. AI aggregated the incident, provided the evidence chain and a proposed plan; he checked the evidence item by item and clicked confirm at the medium-risk gate. The whole process took 9 minutes, and his handling actions were exactly like those of a five-year veteran. In the past, the correct posture for a newcomer on call during their first three months was to watch more and act less. The real value of the gate is that it lets newcomers dare to act—and if they act, nothing catastrophic happens.

The workflow's implementation form is turning SOPs into executable orchestration. Here's a real fragment of one of our automated troubleshooting workflows:

Figure 6: Workflow orchestration canvas. Scheduled triggers, log queries, AI root cause analysis, and conditional judgments are connected by drag-and-drop, and the SOP becomes a runnable process.

Note the guard: requireapproval on the hostbash node. This is the gate: AI can invoke any skill, but every invocation of a high-risk skill must pass human review, and the entire chain is traceable. Capability exposure and risk control must grow together; you can't first get things working through ad-hoc means and then bolt on security—that won't work.

Figure 7: Skill management page. Grouped by "cloud/device," labeled with runtime environment and "safe/requires confirmation" tiers.

Incidentally, every execution leaves an audit trail (input, output, duration, operator), with proactive alerts for abnormal frequency and unauthorized operations. This wasn't forced by compliance requirements; it's muscle memory grown after incidents. In this year's company security audit, we exported the full year's AI execution records: over ten thousand invocations, and for every one we could answer "who, when, on what object, executed what, and with what result." When AI itself needs to be operated and maintained: the awakening moment of LLMOps

Our awakening moment was very concrete. One day, our self-developed AI assistant suddenly became absurd at root cause analysis: for the same type of fault it gave wildly varying root causes—today it said database, tomorrow network, and the day after it started suggesting you restart the switch. Investigation revealed that the upstream model vendor had silently upgraded the version, and behavior had drifted. Traditional monitoring was completely oblivious: CPU, memory, and QPS were all normal, and the system was "healthy." At that moment we realized that probabilistic output cannot be safeguarded by deterministic metrics; a large model is a system that can quietly go bad on its own.

So we treated the LLM as a production system and built a four-piece set.

First, LLM observability. At the invocation level we look at QPS, tokens, latency, and error rate; at the quality level we look at hallucination rate, refusal rate, and human takeover rate—dimensions that simply don't exist in traditional monitoring; at the cost level we break down tokens by skill and by tenant; at the risk level we identify unauthorized invocations and sensitive data exfiltration.

Figure 8: LLM observability. Error rate, hallucinations, token usage, cost, and error type distribution, all on one screen.

Figure 9: LLM call tracing. On the left is the list of error traces; on the right is the input/output and error stack of a single call.

Tracing of a single call must support one-click replay, with every step expandable from user input, prompt assembly, tool invocation, to model output. We once investigated a 401 authentication error where all 90 traces failed; replay pinpointed it to an expired API key of some service, and it took 15 minutes from discovery to fix. Without call tracing, troubleshooting this kind of problem would require adding logs and redeploying.

This trace investigation also left us with a discipline: prompts are code too. Early on, our prompts were scattered across various services; someone made a slip and changed half a line of wording, and the hallucination rate doubled. It took us two days to locate the cause. Since then, all prompts go into the Git repository, are versioned, and changes go through review, enjoying exactly the same release treatment as mapping rules. The first principle of change management in the large model era is: don't treat prompts as text; treat them as code.

Second, quality evaluation—that is, building a quantitative health check for the LLM. We score on 7 dimensions: safety, relevance, accuracy, hallucination, satisfaction, context completeness, and injection protection. Let me highlight a few dimensions.

For the hallucination dimension, we use evidence backtracking. Every conclusion the AI gives is checked against the original data for corresponding evidence; whatever can't be found is a hallucination, and the target is to keep it below 3%. After this detection went live, we found that the hallucination rate of knowledge base Q&A was once close to 10%, with the root cause being poor quality of retrieved chunks. After a month of fixing retrieval, the hallucination rate dropped to just over 2%.

Third, Token economics. Large models aren't cheap, and a platform that doesn't control costs won't last two quarters. We track total cost weekly, break down the share by model, budget by application, and let the AI itself produce cost-reduction suggestions. In the platform, this layer corresponds to cost intelligence FinOps, which looks at Token spend alongside business value and, incidentally, also lets you see cloud resource bills. One suggestion that actually took effect:

We hesitated for a week before daring to put this suggestion into production—after all, what's being saved is real money, and what's being gambled is quality. After launch, sampled scores held steady, the semantic cache hit rate stabilized at around 35%, and not a cent of the savings was lost. The biggest psychological barrier to cost reduction isn't technology; it's who takes the blame if money is saved but something goes wrong. So our approach is canary traffic switching, two weeks of dual-track running, and letting the data speak, so that every cost-reduction decision has a fallback.

Fourth, skill governance. Unify scripts, APIs, and knowledge into skills, and set execution permissions by risk tier. This layer is the governance foundation for the gate in the previous section.

The greatest value of this LLMOps system is that it lets us, for the first time, answer with numbers whether my LLM is actually reliable, rather than deciding based on gut feeling whether it can go to production. Turn experience into Skills, from personal intuition to team assets

At this point, it's time to respond to the proposition from this co-creation plan that moved me most: how to turn operations methods from "one person's intuition" into "a capability asset that can be benchmarked, replicated, and evolved."

Our answer is Skillification. Any troubleshooting playbook, as long as it has been validated more than twice, should be distilled into a skill: what the input is, what it calls, what the judgment criteria are, and what it outputs.

Here's a minimal viable example: distilling "standard troubleshooting for Redis connection refused" into a Skill:

After this Skill went live, the average handling time for Redis connection-refused alerts dropped from 18 minutes to 5 minutes, and any newly onboarded on-call engineer, using the AI to invoke this skill, performs troubleshooting actions exactly the same as a veteran with five years of experience. Experience no longer depends on whether a particular person is on the on-call schedule.

At this pace, over time we distilled dozens of skills in total. Looking back, these dozens of skills are the executable form of our team's operations knowledge base—more alive than the documents on the wiki. The chemistry of the on-call schedule

Now that the methodology is covered, let's talk about something softer, because some changes can't be measured in numbers.

Previously, our rule of thumb for training an operations engineer who could be on call independently was six months: the first three months to get familiar with the system, and the next three months to build up feel by following a veteran. Now this cycle has been compressed to under three months, not because newcomers have become smarter, but because dozens of skills have packed the veterans' feel into the system. When newcomers encounter a problem they haven't seen before, they invoke the skill, and the troubleshooting path is the standard path. At the same time, the other side of turning capabilities into assets is that we must prevent newcomers from knowing only the what but not the why. So we later added a requirement: for any incident handled with AI assistance, the retrospective must answer one question—if there were no AI today, how would you investigate? This question preserves thinking, and it preserves growth.

By the way, let me mention a module related to "peace of mind." I used to think capacity planning in the platform was just a nice-to-have, until once, before a major promotion, it predicted based on historical traffic curves that the order service's connection count would hit the ceiling during peak hours, and gave a scale-out recommendation two weeks in advance. The hidden risk that scale-out averted was exactly the kind of connection pool incident mentioned earlier. So sometimes an incident isn't stopped by a smarter AI; it's stopped by a capacity curve drawn in advance. Not sexy at all, but it really works.

Figure 10: Capacity planning. 90-day capacity forecast curve: current utilization 78%, predicted to reach the 92% ceiling in 30 days; the bottom right shows the scale-out recommendation. The ledger: dare to speak with numbers

Having discussed so much methodology, in the end we have to live up to the word "quantifiable." Our value measurement system revolves around six metrics; here are a few real numbers:

These numbers all have fixed views in the platform—the "Operations Reports" and "MTTR Analysis" sections are exactly for this, so we don't have to manually cobble things together in Excel. MTTR Analysis in particular can slice the view by failure type, by team, and by time period; many of our improvement decisions were made by staring at this chart.

But the ledger also has to include the honest page. You see, MTTR dropped from 38 minutes to 32 minutes 18 seconds, only a 15% reduction, far less impressive than MTTD. Why? We broke MTTR apart and found that detection, localization, and decision-making were all greatly compressed by AI, but the "execution and recovery" segment didn't budge—rollbacks have to go through change approval, and the approval chain is human; whether it should be two signatures or one, not a single one can be skipped. No matter how fast AI is, it can't outrun human processes. This finding actually made us happy, because it directly pointed to the next battleground: bringing the approval process for high-risk operations itself into governance—merging what should be merged, pre-authorizing what should be pre-authorized, on the premise that the evidence chain is trustworthy enough that the person signing can understand in three seconds what they are signing for.

There's also something I often tell the team: if algorithmic accuracy goes from 90% to 95%, and no business metric changes at all, then that 5% improvement may be meaningless. To fellow travelers: a few lessons written in blood

Finally, I'll bring out verbatim a few pitfalls I advise you not to step into.

Don't skip the data foundation and jump straight to algorithms. That's the most common way to die. Unify collection standards, build a solid CMDB and topology, and clean up alert governance—none of this is cool at all, but it's the prerequisite for all intelligence. We've seen too many teams spend 80% of project time patching data holes, only to archive the POC once it's done.

Don't treat alerts as the endpoint. Alerts are just signals; incidents are the governable object. If you only handle alerts without incident aggregation and retrospective capture, the same failure will come back exactly the same way six months later, because the lessons were never retained.

Don't let AI touch production without guardrails. I've seen a real case: a team's black-box scaling system scaled instance count to 8 times normal during a major promotion, costs exploded, and afterward no one could explain why it was 8 times. The hundreds of thousands in direct losses were the small part; the loss of trust was irreversible—that system was never opened again.

Don't let PPT drive AIOps. The right order is to first find a high-frequency, painful-enough scenario with relatively clean data, prove the value, and then talk about platformization. Do it the other way around—build a platform that "can do everything" first and then look for scenarios—and you'll find every scenario falls a bit short, until the platform becomes a dashboard exhibition hall.

Don't wait for perfect data before starting. This sounds contradictory to the first point, but it isn't. Data governance is not a one-time project; it's a companion process. Pick a scenario, take its data from 60 points to 80 points, and that's enough to start—govern while using, and the problems that surface in use are far more real than the ones you plan for. Teams that wait to "govern all the data before deploying AI" generally never see that day, because budget and patience are both finite.

Don't chase the illusion of "unattended operations." At this stage, fully autonomous operations agents are not mature in most enterprises, because the reversibility of operations actions is too poor. The evolution path must be: assist decisions first, then suggest actions, then low-risk autonomous execution, and finally high-risk manual confirmation. Whoever finds the balance between autonomy and safety wins.

Don't think about replacing people. The goal of AIOps is to free people from repetitive labor so they can do more valuable things like architecture optimization and capacity planning. AI replaces tasks, not jobs. The platform is designed with operations participation, the rules are adjustable by operations, and the suggestions can be fed back on by operations—only such a system has vitality. Finally

I mentioned earlier that 3 a.m. wake-up call from 47 alerts—it won't happen again now. Not because we've eliminated failures; failures are always there, and just last month a disk filled up again. What's different is that the moment the failure arrives, the system has already laid out the evidence chain, prepared the suggestions, and left the guardrail position ready—all the on-call engineer needs to do is the final two clicks.

This is probably what I've truly wanted after all these years in AIOps: not a cooler architecture, but frontline colleagues no longer having to piece things together in the middle of the night; experience no longer draining away as people come and go; and when the system is too complex for one brain to hold, a digital brain still carrying it for us.

From seeing, to understanding, to acting, and then to making the actions themselves governable, retainable, and replicable.