docs(airflow_tags): add impact/tier_0 and update tier SLA descriptions - #9836
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Docs-only change to docs/reference/airflow_tags.md: adds an impact/tier_0 bullet and rewrites the impact/tier_1 and impact/tier_2 descriptions with explicit resolution expectations. impact/tier_3 is unchanged.
I confirmed there's no allow-list or enum validating DAG tags in bigquery_etl/query_scheduling/ or bigquery_etl/cli/dag.py, so impact/tier_0 can be used in dags.yaml without a code change. Note that no DAG in this repo is tagged impact/tier_0 yet, and copy_deduplicate_task_markers.py:106 hardcodes impact/tier_1 for the copy-dedupe marker DAG even though copy dedupe is now the leading tier 0 example — worth a follow-up if retagging is intended.
|
|
||
| - **impact/tier_1**: Highest priority/impact/critical DAG. A job with this tag implies that many downstream processes are impacted and affects Mozilla’s (many users across different teams and departments) ability to make decisions. A bug ticket must be created and the issue needs to be resolved as soon as possible. | ||
| - **impact/tier_2**: Job of increased importance and impact, however, not critical and only limited impact on other processes. One team or group of people is affected and the pipeline does not generate any business critical metrics. A bug ticket must be created and should be addressed within a few working days. | ||
| - **impact/tier_0**: Foundational pipelines that a significant portion of downstream data processing depends on (e.g. copy dedupe, Glean usage). A Tier 0 failure takes priority over all other work — all hands on deck, must fix ASAP. A bug ticket must be created immediately and the issue worked until it is resolved or explicitly handed off to someone who has accepted ownership. |
There was a problem hiding this comment.
suggestion: The unchanged preamble on line 14 says "We borrow the [tiering system] used by our integration and testing sheriffs... to maintain a level of consistency across different systems to ensure common language and understanding across teams." The linked Job Visibility Policy defines only tiers 1–3, and with this PR the tier_1/tier_2 definitions are also rewritten in terms of data pipelines and SLAs rather than the sheriff definitions. Reword line 14 to say the tiering is inspired by / adapted from the sheriffs' system with a data-pipeline-specific tier 0, so the doc doesn't claim a consistency that no longer holds.
Co-authored-by: Lucia <30448600+lucia-vargas-a@users.noreply.github.com>
2 participants
Description
Adds tier 0 to docs and updated SLA descriptions
Related Tickets & Documents
Reviewer, please follow this checklist