Ernst van Nierop
--- a/data/team.yml
+++ b/data/team.yml
  locality: Hilversum
--- a/source/handbook/infrastructure/index.html.md
+++ b/source/handbook/infrastructure/index.html.md
-
-1. Security: reduce risk to its minimum, and make the minimum explicit.
-1. Transparency, clarity and directness: public and explicit by default, we work in the open, we strive to get signal over noise.
-1. Efficiency: smart resource usage, we should not fix scalability problems by throwing more resources at it but by understanding where the waste is happening and then working to make it disappear. We should work hard to reduce toil to a minimum by automating all the boring work out of our way.
+  - [Public monitoring infrastructure](http://monitor.gitlab.net/):
+    - No auth is required
+    - Automatically syncs from the private monitoring infrastructure on every chef client execution. Don't change dashboards here, they will be overwritten.
+  - [Private monitoring infrastructure](https://performance.gitlab.net):
+    - Highly Available setup
+    - Alerting feeds from this setup
+    - Toggle "public" to have the dashboard appear on the Public monitoring infrastructure. **Default to making public, unless you can specify a good reason not to**.
+    - Private GitLab account is required to access
+    - Separated from the public for security and availability reasons, they should have exactly the same graphs after we deprecate InfluxDB

-#### Production and Staging Access
+## Production and Staging Access
--- a/source/handbook/infrastructure/index.html.md
+++ b/source/handbook/infrastructure/index.html.md
-  - You can find the infrastructure archive [here](https://docs.google.com/document/d/19yzyIHY9F_m5p0B0e6STSZyhzfo-vLIRVQ1zRRevWRM/edit#heading=h.lz1c6r6c9ejd).
-  Automated tasks and schedules
-  - Weekly automatic OS updates are performed on Monday at 10:10 UTC.
- Monitoring: we do monitoring with prometheus leveraging available exporters like the node or the postgresql exporters, and we build whatever else is necessary within production engineering itself. We maintain 2 monitoring infrastructures:
-  - [Public monitoring infrastructure](http://monitor.gitlab.net/):
-    - No auth is required
-    - Is automatically sync from the private monitoring infrastructure on every chef client execution. Don't change dashboards here, they will be overwritten.
-  - [Private monitoring infrastructure](https://performance.gitlab.net):
-    - Highly Available setup
-    - Alerting feeds from this setup
-    - Private GitLab account is required to access
-    - Separated from the public for security and availability reasons, they should have exactly the same graphs after we deprecate InfluxDB
+## Automated tasks and schedules

-## Documentation
+Weekly automatic OS updates are performed on Monday at 10:10 UTC.
--- a/source/handbook/infrastructure/production/index.html.md 0 → 100644
+++ b/source/handbook/infrastructure/production/index.html.md 0 → 100644
+
+Production engineers also have a strong focus on building the right toolsets
+and automations to enable development to ship features as fast and bug free as
+possible, leveraging the tools provided by GitLab.com itself - we must dogfood.
+
+Another part of the job is building monitoring tools that allow quick
+troubleshooting as a first step, then turning this into alerts to notify based on
+symptoms, to then fixing the problem or automating the remediation. We can only scale
+GitLab.com by being smart and using resources effectively, starting with our
+own time as the main scarce resource.
+
+### Tenets
+
+1. Security: reduce risk to its minimum, and make the minimum explicit.
+1. Transparency, clarity and directness: public and explicit by default, we work in the open, we strive to get signal over noise.
+1. Efficiency: smart resource usage, we should not fix scalability problems by throwing more resources at it but by understanding where the waste is happening and then working to make it disappear. We should work hard to reduce toil to a minimum by automating all the boring work out of our way.
--- a/source/handbook/infrastructure/production/index.html.md 0 → 100644
+++ b/source/handbook/infrastructure/production/index.html.md 0 → 100644
+
+
+## Prioritizing Issues
+
+Given the variety of responsibilities and number of "interfaces" between the Production
+team and all the other teams at GitLab, here is a guideline on how to prioritize
+the issues we work on. Basing this on the [goals of the Infrastructure team](../#infragoals) as
+well as our [values](/handbook/values/) and [workflows](handbook/engineering/workflow)
+as a company as whole, the priority should be:
+
+1. keeping GitLab.com available - and secure
+1. unblocking others
+1. automating tasks to reduce toil and increase _team_ availability (but be explicit about the costs and benefits)
+1. improving performance of GitLab.com while being conscious of cost
+1. reducing costs of running GitLab.com
+
--- a/source/handbook/infrastructure/production/index.html.md 0 → 100644
+++ b/source/handbook/infrastructure/production/index.html.md 0 → 100644
+1. reducing costs of running GitLab.com
+
+### Labeling Issues
+
+We use [issue labels](https://gitlab.com/gitlab-com/infrastructure/labels) to
+assist in organizing issues within the Infrastructure issue tracker. Prioritized labels are
+
+- `~critical`
+- `~security`
+- `~chef`
+- `~noise`
+- `~blocked`
+
+Issues in this tracker should be organized into [boards](https://gitlab.com/gitlab-com/infrastructure/boards)
+ and [milestones](https://gitlab.com/gitlab-com/infrastructure/milestones) to define projects and timelines respectively.
+
--- a/source/handbook/infrastructure/production/index.html.md 0 → 100644
+++ b/source/handbook/infrastructure/production/index.html.md 0 → 100644
+### Labeling Issues
+
+We use [issue labels](https://gitlab.com/gitlab-com/infrastructure/labels) to
+assist in organizing issues within the Infrastructure issue tracker. Prioritized labels are
+
+- `~critical`
+- `~security`
+- `~chef`
+- `~noise`
+- `~blocked`
+
+Issues in this tracker should be organized into [boards](https://gitlab.com/gitlab-com/infrastructure/boards)
+ and [milestones](https://gitlab.com/gitlab-com/infrastructure/milestones) to define projects and timelines respectively.
+
+### Production Priority Labels
+
--- a/source/handbook/infrastructure/production/index.html.md 0 → 100644
+++ b/source/handbook/infrastructure/production/index.html.md 0 → 100644
+     - Performance improvement (or avoiding degradation) likely, but not clear if a lot.
+     - Cost reduction by $10k/yr
+  - I3
+     - No outage expected from this.
+     - Toil/noise reduction by <= 30 mins per week.
+     - No significant performance improvement (or avoiding degradation).
+     - No significant cost reduction.
+
+
+| **Urgency \ Impact**          | **I1 - High** | **I2 - Medium**  | **I3 - Low**   |
+|----------------------------|---------------|------------------|----------------|
+| **U1 - High**              | `PP1`         | `PP1`            | `PP2`          |
+| **U2 - Medium**            | `PP1`         | `PP2`            | `PP3`          |
+| **U3 - Low**               | `PP2`         | `PP3`            | `PP3`          |
+
+## Production events logging
--- a/source/handbook/infrastructure/index.html.md
+++ b/source/handbook/infrastructure/index.html.md

-Production engineers also have a strong focus on building the right toolsets
-and automations to enable development to ship features as fast and bug free as
-possible, leveraging the tools provided by GitLab.com itself - we must dogfood.

-Another part of the job is building monitoring tools that allow quick
-troubleshooting as a first step, then turning this into alerts to notify based on
-symptoms, to then fixing the problem or automating the remediation. We can only scale
-GitLab.com by being smart and using resources effectively, starting with our
-own time as the main scarce resource.
+## Monitoring

-[Production Engineer](jobs/production-engineer/index.html) job description.
+We do monitoring with Prometheus, leveraging available exporters like the node
+or the postgresql exporters, and we build whatever else is necessary within
+production engineering itself. We maintain 2 monitoring infrastructures:
--- a/source/handbook/infrastructure/index.html.md
+++ b/source/handbook/infrastructure/index.html.md

 Any other engineer, or lead, or manager at any level will not have access to production, and, in case some information is needed from production it must be obtained by a production engineer through an issue in the infrastructure issue tracker.
--- a/source/handbook/infrastructure/index.html.md
+++ b/source/handbook/infrastructure/index.html.md

 Any other engineer, or lead, or manager at any level will not have access to production, and, in case some information is needed from production it must be obtained by a production engineer through an issue in the infrastructure issue tracker.

-There is one temporary exception: [release managers](/release-managers) require production access to perform deploys, they will have production access until production engineering can offer a deployment automation that does not require chef nor ssh access. This is an ongoing effort.
+There is one temporary exception: release managers require production access to perform deploys, they will have production access until production engineering can offer a deployment automation that does not require chef nor ssh access. This is an ongoing effort.
--- a/source/handbook/infrastructure/index.html.md
+++ b/source/handbook/infrastructure/index.html.md
- What to do when: points to specific runbooks to run on stressful situations (on-call)
- How do I: points to general administration texts that explain how to perform different administration tasks.
+- _What to do when_: points to specific runbooks to run in stressful situations (on-call)
+- _How do I_: points to general administration texts that explain how to perform different administration tasks.

 When writing a new runbook, be mindful what the goal of it is:

+- General documentation that customers may also benefit from: don't write it in the runbooks, write it into [GitLab documentation](https://docs.gitlab.com/).
 - If it is for on-call situations, make it crisp and brief. Try to keep the following structure: pre-check, resolution, post-check .
 - If it is for general management, it can be freely formatted.

-### Chef cookbooks
+## Chef cookbooks
+
+Generally our [chef cookbooks](https://gitlab.com/groups/gitlab-cookbooks) live in the open, and they get mirrored back to our
+[internal cookbooks group](https://dev.gitlab.org/cookbooks) for availability reasons.
--- a/source/handbook/infrastructure/index.html.md
+++ b/source/handbook/infrastructure/index.html.md
 - Cookbooks should be developed using the team. We use merge requests and code review to share knowledge and build the best product we can.
 - Cookbooks should be covered with ChefSpec and TestKitchen testing in order to ensure they do what they are supposed to and don't have conflicts.

-Generally our [chef cookbooks](https://gitlab.com/groups/gitlab-cookbooks) live in the open, and they get mirrored back to our
-[internal cookbooks group](https://dev.gitlab.org/cookbooks) for availability reasons.
+There may be cases of cookbooks that could become a security concern, in which case it is OK to keep them on our GitLab
+private instance. This should be assessed on a case by case basis, and documented properly.
--- a/source/handbook/infrastructure/index.html.md
+++ b/source/handbook/infrastructure/index.html.md
 - Cookbooks should be developed using the team. We use merge requests and code review to share knowledge and build the best product we can.
 - Cookbooks should be covered with ChefSpec and TestKitchen testing in order to ensure they do what they are supposed to and don't have conflicts.

-Generally our [chef cookbooks](https://gitlab.com/groups/gitlab-cookbooks) live in the open, and they get mirrored back to our
-[internal cookbooks group](https://dev.gitlab.org/cookbooks) for availability reasons.
+There may be cases of cookbooks that could become a security concern, in which case it is OK to keep them on our GitLab
+private instance. This should be assessed on a case by case basis, and documented properly.

-There may be cases of cookbooks that could become a security concern, in which case it is ok to keep them in our GitLab
-private instance. This should be assessed in a case by case and documented properly.
+### Documentation specific to GitLab.com

-### Internal documentation
+There is some documentation that is specific to GitLab.com available in the [private Chef Repo](https://dev.gitlab.org/cookbooks/chef-repo).
+Things that are specific to our infrastructure
+providers or that would create a security threat for our installation are documented there.