Team Knowledge

guided tour · part 3 of 5 resolve overview docid\ ctmycol8s0io8g1giztix → connect an integration docid\ ig yfnpcmge2yt3oq5i4b → team knowledge → auto investigations docid 3moxjnu2unbupnw evgda → tuning accuracy docid mempyfopnqpmkk 1vowo the more resolve knows about your systems, the better it debugs your issues investigations get faster and more accurate when resolve knows your system's quirks, your team's best practices, and where to look first this part of the series introduces the different kinds of knowledge you can give resolve and how to add them for the complete, step by step reference, follow the knowledge setup guide docid\ ejosivxhatgxk4mm4ngbd this page is the guided tour multiple tiers organization, team, and individual (via skills) resolve organizes knowledge into multiple tiers organization — knowledge that applies company wide team — knowledge specific to a single team when both exist, team knowledge takes priority individual — package your own repeatable procedures as skills docid\ nlilpthw611fjeawk8o0k for the tasks you perform often for example, an e commerce app organization might have several teams, each with their own runbooks and dashboards, plus a shared set of org level knowledge you manage all of it from teams & knowledge docid\ m4f0bsnc1so f7zedqxrw the types of knowledge within the org or any team, you can define several kinds of knowledge each is covered in depth in the knowledge setup guide docid\ ejosivxhatgxk4mm4ngbd 1\ resolve md a short, freeform description of your system — the equivalent of the readme you'd hand a new engineer start simple add a few lines, then grow it as investigations reveal what's missing see resolve md in the setup guide docid\ ejosivxhatgxk4mm4ngbd 2\ alert runbooks attach a runbook to any alert filter so resolve follows your team's exact investigation steps when that alert fires from an alert (for example, front end error logs above threshold ), add a runbook by linking an existing document or creating a new one right inside resolve runbooks are what make auto investigations docid 3moxjnu2unbupnw evgda follow your playbook — see alert runbooks docid\ ejosivxhatgxk4mm4ngbd 3\ dashboard guidance add the dashboards your team relies on, under your org or team when you add a dashboard, resolve automatically summarizes it and generates pointers for how to read it you can edit those pointers — for example, "this is a load testing dashboard; a load test is running when this metric spikes " dashboards come from your connected observability tools like datadog docid 01qujrn1ic nfrqfwi8ky , grafana docid 3o0xazovxfakduiv5eamn , or new relic docid\ ayxqus2yp8z26wfj bnel see dashboard guidance docid\ ejosivxhatgxk4mm4ngbd 4\ docs general documentation resolve pulls in when relevant during an investigation or incident — post mortems, architecture notes, general guidance add them under docs for the team or org see docs docid\ ejosivxhatgxk4mm4ngbd 5\ skills skills package repeatable, multi step procedures resolve can run on demand or as slash commands they sit alongside the rest of your knowledge — see skills docid\ nlilpthw611fjeawk8o0k already have this knowledge elsewhere? import runbooks, docs, and skills from confluence (via atlassian docid\ u2wogjwebnhoxxkuw8ab2 ) or a git repo (via the app for github docid\ pged2nyyvxb534oykekqi ) — resolve keeps them in sync with the source see importing from external sources docid\ ejosivxhatgxk4mm4ngbd tools like glean docid hedpjljimzsz ffr0lla are different resolve queries them live as evidence during investigations rather than importing them as team knowledge close the loop with feedback how do you know your knowledge is actually helping? open any investigation and use the thumbs up / thumbs down control thumbs up — note what made it helpful thumbs down — note what needs to improve resolve uses this feedback to improve future investigations, and you can review all of it later this feedback loop is the core of part 4 — tuning accuracy docid mempyfopnqpmkk 1vowo start with the basics, then iterate you don't need an exhaustive document on day one, but a small baseline makes investigations far better right away for each team, seed a resolve md docid\ ejosivxhatgxk4mm4ngbd with system architecture — what the team owns key services, repos, and environments/clusters team dictionary — acronyms, abbreviations, and internal terminology logs & traces guidance — which indexes and filters to use, the order to apply them, and an example query or two deployment guidance — where resolve can find deploys, feature flag, and config changes (especially if it lacks direct ci/cd access) from there, add investigation and attribution guidance and alert runbooks docid\ ejosivxhatgxk4mm4ngbd as real alerts come in — keeping new knowledge grounded in real investigations instead of one long document written up front what's next with knowledge in place, you're ready to let resolve work automatically — triaging and investigating alerts the moment they fire next part 4 — auto investigations docid 3moxjnu2unbupnw evgda previous part 2 — connect an integration docid\ ig yfnpcmge2yt3oq5i4b