From 0734268b74abdf60de8b4db2b005bf3782e00387 Mon Sep 17 00:00:00 2001 From: Rik Date: Tue, 26 Mar 2024 18:07:13 +0100 Subject: [PATCH 1/4] Add Rik onboarding patches (#8753) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit User pain point @arafatkatze ? 😋 ![CleanShot 2024-03-21 at 14 49 15@2x](https://github.com/sourcegraph/handbook/assets/3949285/1d41d6f4-26c0-47cf-b9f7-df8372b8ad6e) --- .../resources-for-new-hires/new-teammate-setup.md | 8 ++++++++ content/team/locations.geojson | 15 ++++++++++++++- data/team.yml | 12 ++++++++++++ 3 files changed, 34 insertions(+), 1 deletion(-) diff --git a/content/departments/people-talent/resources-for-new-hires/new-teammate-setup.md b/content/departments/people-talent/resources-for-new-hires/new-teammate-setup.md index f7b7ec52a583..570b69889c7e 100644 --- a/content/departments/people-talent/resources-for-new-hires/new-teammate-setup.md +++ b/content/departments/people-talent/resources-for-new-hires/new-teammate-setup.md @@ -44,6 +44,14 @@ You can find resources on how to use each of the main tools [here](../../../comp - Join the Sourcegraph events calendar by copying `sourcegraph.com_9cd67o8p3gs0rtpj73bt326psk@group.calendar.google.com` into your [add calendar field](https://calendar.google.com/calendar/u/0/r/settings/addcalendar?) +- A good way to get to know your team is to try and schedule a regular 1-on-1 or fika ([https://go/fika](https://go/fika)) with them. To avoid overwhelming yourself with all the scheduling of these meetings you can create an Appointment Schedule. This allows you to specify time slots that work for you and then share a link for your teammates to pick a slot that works best for them. Very similar to Calendly if you've used that before. + +![How to create an appointment schedule](https://storage.googleapis.com/sourcegraph-assets/handbook/appointment-schedule.jpg) + +After a meeting is scheduled you can change the interval to a standing invite and give them the ability to modify the event to help with any future rescheduling. + +![Standing invite](https://storage.googleapis.com/sourcegraph-assets/handbook/appointment-schedule-standing-invite.jpg) + - See the Communication handbook for [more on scheduling meetings](../../../company-info-and-process/communication/index.md#scheduling-meetings-with-google-calendar). ## Slack diff --git a/content/team/locations.geojson b/content/team/locations.geojson index 94b097364cda..be8784e27c60 100644 --- a/content/team/locations.geojson +++ b/content/team/locations.geojson @@ -780,6 +780,19 @@ 52.513384 ] } + }, + { + "type": "Feature", + "properties": { + "name": "Rik Nauta" + }, + "geometry": { + "type": "Point", + "coordinates": [ + 13.000640, + 55.595330 + ] + } } ] -} +} \ No newline at end of file diff --git a/data/team.yml b/data/team.yml index dba4268e707e..329656d5dd97 100644 --- a/data/team.yml +++ b/data/team.yml @@ -1828,3 +1828,15 @@ anish_lakhwara: location: Vancouver, Canada 🇨🇦 links: '[LinkedIn](https://www.linkedin.com/in/anish-lakhwara-0a62651bb/), [Website](https://anish.lakhwara.com)' description: Anish was born in Australia, raised in India, and now calls Canada home. Ever interested in computing, Anish enjoys building and contributing to open source, tinkering on his nvim config, and playing with shiny new tools. Always open to learning more, and aspiring to be a good engineer and a great human. When not touching computers, Anish likes rock climbing, sailing, gardening, and annoying his very loud cat, Imoh. + +rik_nauta: + name: Rik Nauta + role: Software Engineer + reports_to: cody_strat_lead + location: Malmö, Sweden 🇸🇪 + github: RXminuS + email: rik.nauta@sourcegraph.com + links: '[LinkedIn](https://www.linkedin.com/in/riknauta/)' + pronouns: He/Him or They/Them + pronunciation: '[pronounce my name 🔊](https://www.name-coach.com/rik-nauta)' + description: Originally from the Netherlands, Rik has called Sweden his home over the last 16 years. Although he was on the brink of completing his MSc in Engineering Physics, his fascination with AI (and apathy towards particles) led him to forgo his final course to create a company dedicated to developing an AI-powered contract writing assistant instead. Outside of his professional endeavors Rik is an avid skiier and a regular foster parent to guide-dog puppies and "problem" doggos. Rik's unique superpower is his remarkable ability to nap under any circumstances. From 7f7dd2261ea06760c8990ab88bc5a70bc266888e Mon Sep 17 00:00:00 2001 From: TrevorHoughton <83668790+TrevorHoughton@users.noreply.github.com> Date: Tue, 26 Mar 2024 12:31:24 -0700 Subject: [PATCH 2/4] Updated EAE sales presentation doc (#8776) --- .../people-talent/talent/process/types_of_interviews.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/departments/people-talent/talent/process/types_of_interviews.md b/content/departments/people-talent/talent/process/types_of_interviews.md index bf7b2882cb22..10635bf76a68 100644 --- a/content/departments/people-talent/talent/process/types_of_interviews.md +++ b/content/departments/people-talent/talent/process/types_of_interviews.md @@ -860,7 +860,7 @@ A great resource on structure (including some great walkthrough videos) from [Be - Interviewer(s): Hiring Manager + Account Executive(s) - Duration: 45-minutes. - Purpose: during the sales presentation, you will 1) walk the panel through a brief introduction/bio of yourself, 2) deep-dive into an enterprise deal you have led, and 3) present a pipeline generation plan (including 10 top target accounts you would pursue based on your understanding of Sourcegraph's value proposition, your personal relationships, and relevant information about the prospect companies that you believe lead to a high probability of engagement). The goal of this interview is for us to understand: 1) your past experience and skill set (via your intro), 2) whether you can command a sales process (via the deep-dive), and 3) your understanding of our value proposition and approach towards territory development. -- **Very important:** please use [this template](https://docs.google.com/presentation/d/1Tl5XdoMog8QEzEZFAHVHrOYAfjlOh7tomZKlVdxwGeA/edit#slide=id.g9288fdfdea_0_109) for your presentation and please check out the speaker notes - they have a lot of detail on what we are looking for! If you have any issues accessing the presentation, please email recruiting@sourcegraph.com. +- **Very important:** please use [this template](https://docs.google.com/presentation/d/1uERGh_qcNiaLhTjln_lserWk6Ep_ewOQO6rkLvpwm-M/edit#slide=id.g9288fdfdea_0_109) for your presentation and please check out the speaker notes - they have a lot of detail on what we are looking for! If you have any issues accessing the presentation, please email recruiting@sourcegraph.com. #### Enterprise AE team collaboration with Customer Engineering From 6b7e4f46a89cfb85b1a94e56b32c2d0fa067eb78 Mon Sep 17 00:00:00 2001 From: ErikaRS Date: Tue, 26 Mar 2024 17:05:31 -0700 Subject: [PATCH 3/4] Update PFP doc to v2 (#8777) Updating the handbook to reflect the move from time based PFP planning to queue based PFP planning. --------- Co-authored-by: ErikaRS --- .../engineering/product-planning.md | 282 ++++++++++++------ 1 file changed, 195 insertions(+), 87 deletions(-) diff --git a/content/departments/engineering/product-planning.md b/content/departments/engineering/product-planning.md index 4042a55bf9ff..b1cca99f9113 100644 --- a/content/departments/engineering/product-planning.md +++ b/content/departments/engineering/product-planning.md @@ -4,92 +4,200 @@ ## Product-Focused Planning -Each planning cycle (currently quarterly), the overall goals come from the exec -team to make sure we're driving towards the destination we've set for ourselves -as a company in our strategy and roadmap. +Our product planning and execution strategy is designed to align with the +company's strategic objectives, marketing goals, and feedback from our +customers. Planning is continuous with quarterly check-ins. -It's the product teams – engineering and product together – that have the +It’s the EPD teams – product, engineering, and design together – that have the expertise, context and pride of ownership to be best suited to propose the -highest impact work that fits those goals. And they're the team that can do -the correct [eng scoping](#engineer-scoping). - -Per-team planning reviews are where we come together to ensure we're happy with -where we're headed at each planning cycle. TPMs will pull together reviews for -each team each planning cycle to include interested members of the exec team, -the leads of the product team (at least the EPD triad) and other interested -stakeholders. A planning review will consist of content to cover at least the -following topics: - -- **Retrospective:** How well did we do in accomplishing our goals from last Q? - What data do you have to support those conclusions? -- **Status:** How well is the product serving the needs of our customers and the - business? How well have you hit your metrics targets? -- **Plans:** What work is being proposed for this planning cycle, how does it meet - the business goals and how does it serve the needs of our customers? What - data are you using to drive your planning? Have you done the high-level - [eng scoping](#engineer-scoping) to give you confidence that your team will be - able to get the P0 work done in the time? -- **Success Metrics:** what KPIs and targets have you set to measure the success - of this work? -- **Risks/Open Questions/Needs:** What are the biggests risks? What are the - mitigations? What guidance would you like from the exec team? Do you - have everything you need to be successful? -- **Excluded:** What alternatives have you rejected for this Q and why? Will they - be on the team's roadmap for the future? - -The purpose of the planning review is for each product team to present their -proposed work for that cycle and to hear feedback from the exec team as to whether -there is agreement about the direction and tasks that the product team's proposals -or whether adjustments need to be made. At the end of a review, the execs and -the product team will either be in alignment about the work to do done that cycle -or another review meeting will be scheduled to follow up until there is alignment. - -Note, not every team will have work to do that applies to every goal every -quarter. Likewise, not every work item is expected to meet a strategic goal. - -## Review Effectiveness - -Some tips for having an effective review: - -- **Make sure the priorities for your work is clear** -- what's Must Have (P0), - Want To Have (P1) and Nice To Have (P2)? What could get cut? -- **Make sure the customer (internal and/or external) impact is clear** -- if - we do this work, what's going to be the value to the customer? -- **Make sure the business impact is clear** -- if we do this work, how does that - help us achieve our strategic goals? -- In addition to ensuring that the EPD team is aligned before heading into the - review, **try to get as much alignment with execs ahead of time as possible.** - -I've noticed that the teams the follow this tips have a smoother review process. - -## Engineer Scoping - -For any launch, we have a finite amount of time and a finite number of engineers. -Before the PFP review, EPD should have done a high level assessment to ensure a -high level of confidence in the P0 items in the work plan. - -After the team's plan has been approved, EPD's detailed planning should include -an "eng scoping" exercise, i.e. - -1. What is the eng effort associated with each of the P0 and P1 items, e.g. 2 - days or 3 weeks or ...? [Here's an example of one such exercise.](https://docs.google.com/spreadsheets/d/1adlwcMWHIpDGioBkE9LUdLMHxprtxhh_WSZqxu6Iyxs/edit#gid=0) -1. Given the priorities and the eng effort required for each item, where do we - draw the line of what we can accomplish for our launch? Ideally it includes all - of the P0s. If it doesn't, we have to mitigate. -1. Mitigate the implications of the where the line between what we need (P0s), - what we want (P1s) and our actual eng effort. Can we get all of the P0s in? - If not, then what do we do? Continue cutting scope? Slip the release? - -The eng scoping work is the difference between eyeballing a list of requirements -and hoping we can get them all done and actually having some confidence that -we can accomplish what we want. And if we can't, we want to know that ASAP so -we can cut scope for our release. - -## Priorities - -To make sure we're talking about the same thing as we assign priorities to the -items in our plans, we've adopted the following convention: - -- P0: Committed -- P1: Stretch -- P2: Uncommitted +highest impact work that fits those goals. And they’re the team that can do the +correct eng scoping. + +### Planning Process + +Planning is continuous, guided by the [company's strategic +objectives](https://docs.google.com/document/d/1Ju2SwpRCcIAC65kCu60QM8rnsn8YDTmkNAKO5xkl0ZY/edit#heading=h.ev1rhjc47atd), +[product +strategy](https://docs.google.com/document/d/1VxVbjskzTB4m9mvm3w5xtmFRDTxj1e5N3yEftEH2Nsw/edit#heading=h.mj1qne1whw0t), +marketing goals, feedback from our customers, especially [GTM-tracked product +gaps](https://sourcegraph2020.lightning.force.com/lightning/r/Report/00O3t000006WZklEAG/view?reportFilters=%5B%7B%22operator%22%3A%22equals%22%2C%22value%22%3A%22Cody%22%2C%22column%22%3A%22Product_Gap_Submission__c.Product_Category__c%22%7D%5D), +and internal needs (e.g., scalability, reliability, performance, security). + +We expect that the rough  distribution of work will be about 50% based on the +strategic objectives (which drive our marketing launches). The other 50% of the +work will come bottoms up from customer feedback and internal needs. Across all +of this work, aim to keep Enterprise focused work at 20% or less as per our +“feature conveyor belt.” + +Work items from these input sources are divided into three categories: + +- **Work In Progress (WIP):** Already started. WIP has specified target dates, based on the work's scope and requirements. + - By default, WIP should not be interrupted. +- **Next queue:** A short (max 5) ordered list of planned work without target dates. This work should represent the team’s most important upcoming work, across all categories. + - This can be reordered or added to (up to the limit) without notification of stakeholders but no approval needed. Removing items requires approval from stakeholders for that item, Head of Product, and Head of Eng. +- **Backlog:** An unordered set of work with no associated target or commitment dates. + +New work items are triaged into one of these three categories (see the FAQ for details). + +Work can have two types of dates: + +- **Target dates:** Set only for Work In Progress. Gives stakeholders a rough idea of when the work might be delivered. + - Can be changed by the team at will, giving the team flexibility to adjust based on trade-offs between date and scope. +- **Commitment dates:** Set for work with external-to-EPD commitments. Work can be committed without yet being started. + - Changing a commitment date requires approval from the stakeholders involved. + +### Quarterly Check-ins + +Per-team check-ins are where we come together to ensure we’re aware of progress +and aligned with direction. The purpose of the planning review is for each team +to present their progress, a snapshot of their planned work, and get feedback +from the exec team. + +A planning review will consist of content to cover at least the following +topics: + +- Retrospective: + - How well did we do in accomplishing our goals since last quarter? + - What data supports those conclusions? +- Status: + - How well is the product serving the needs of our customers and the business? + - How well have you hit your metrics targets? +- Plan snapshot: + - What are your external commitments? What is the current Work In Progress? What work items are Next? + - How does this work meet our business goals and how does it serve the needs of our customers? + - What data are you using to drive your planning? + - Have you done the high-level eng scoping to give you confidence that your team will be able to get committed work done by the committed date? + - Note, not every team will have work that applies to every goal. Likewise, not every work item is expected to meet a strategic goal. +- Success Metrics: + - What KPIs and targets have you set to measure the success of this work? +- Risks/Open Questions/Needs: + - What are the biggests risks? What are the mitigations? + - What guidance would you like from the exec team? + - Do you have everything you need to be successful? +- Excluded: + - What items in your Backlog are just below the line? + - What requests to your team have you decided not to put on your Backlog at all? + +TPMs will schedule reviews for each team throughout the quarter to include +interested members of the exec team, the leads of the product team (at least the +EPD triad) and other interested stakeholders. At the end of a review, the execs +and the product team will either be in alignment or the team will address the +concerns and schedule a follow-up (repeat as needed). + +## FAQ + +**Q: How do we prioritize work without the planning process?** + +A: When prioritizing work (new or backlogged), the team should go through the following process: + +- Does this work have an external commitment date? When does the work need to be started to meet that commitment date? + - Changing a commitment date or the scope of a commitment requires buy in from the relevant stakeholders. +- Should this work interrupt Work In Progress? + - Default answer is no! Interrupting Work In Progress should occur only for unavoidably urgent work like an incident or a commitment with a date outside of our control. +- If it shouldn’t interrupt Work In Progress, should it go in the Next queue? If so, where? + - If the Next queue gets longer than 5 items, the team will have to remove work items to ensure that the team is focused on a small set of top priorities. When items are removed from the Next queue, stakeholders should be informed. +- If it’s not Next, add it to the Backlog (or close as won’t fix). + +**Q: Where does new work come from?** + +Strategic goals and product roadmap + +- The product roadmap evolves based on customer needs, the competitive landscape, and customer feedback. The Product team owns the [product roadmap](https://docs.google.com/document/d/1XehlyVYzyUP7jClMJB7NV-RyKyI4X14zkQ2N8Us4Q48/edit#heading=h.3yu1a6dm5wpq), and PMs are responsible for working roadmap updates into team plans. + +Marketing goals + +- Marketing moments should deliver a cohesive and impactful set of features that support the marketing narrative. When Marketing wants to plan a marketing moment, they will coordinate with Product to adjust the [product roadmap](https://docs.google.com/document/d/1XehlyVYzyUP7jClMJB7NV-RyKyI4X14zkQ2N8Us4Q48/edit#heading=h.3yu1a6dm5wpq) 3-6 months before the planned event. They will specify a commitment date that provides sufficient lead time for Marketing to integrate the completed work into their narrative. + +Customer Feedback and GTM Requests + +- Product Managers are responsible for aggregating customer feedback across different channels and working it into the [product roadmap](https://docs.google.com/document/d/1XehlyVYzyUP7jClMJB7NV-RyKyI4X14zkQ2N8Us4Q48/edit#heading=h.3yu1a6dm5wpq) and team plans (small customer feedback items do not need to be in the roadmap). (This will be aided by ongoing investments to make Salesforce Product Gaps more self-serve.) + +Internal needs + +- Engineering, Product, and Design teammates will have items that need to be addressed to meet foundational goals such as scalability, reliability, performance, and security. This includes ongoing maintenance, architectural improvements, and polishing of existing features. + +**Q: What prevents teams from letting scope creep and never shipping?** + +A: Teams will need to give quarterly updates on their progress at the check-ins. +This is one mechanism for incentivizing teams to break work into smaller, +shippable chunks. + +We’ll also need teams to incorporate the idea of [stepping +stones](https://medium.com/@jamesacowling/stepping-stones-not-milestones-e6be0073563f) +into their planning process: how do we break large projects into smaller, more +manageable chunks that are “shippable and stoppable”. That is, pieces that can +be shipped independently and which also add value such that even if the larger +project were to stop, the project still delivered value. + +**Q: If planning is rolling, how do we know we’re working on the most important things?** + +A: The Product Managers own the Next queue for each team and are responsible for +making sure that it’s aligned with the [company’s strategic +objectives](https://docs.google.com/document/d/1Ju2SwpRCcIAC65kCu60QM8rnsn8YDTmkNAKO5xkl0ZY/edit#heading=h.ev1rhjc47atd) +and [product +strategy](https://docs.google.com/document/d/1VxVbjskzTB4m9mvm3w5xtmFRDTxj1e5N3yEftEH2Nsw/edit#heading=h.mj1ķne1whw0t). +If the PMs are concerned that a team does not have enough high impact work (or +too much!), they are responsible for working with leadership and EMs to figure +out how to better align the team with our strategic goals. + +**Q: What is the source of truth for plans? How do we keep leadership informed and aligned?** + +For high level checks, the quarterly check-ins will inform and align. + +The [product +roadmap](https://docs.google.com/document/d/1XehlyVYzyUP7jClMJB7NV-RyKyI4X14zkQ2N8Us4Q48/edit#heading=h.3yu1a6dm5wpq) +is the source of truth of teams’ work (although it doesn’t include internally +focused team work or smaller customer feedback work items). Over time, the TPM +team will develop processes so that leadership can go to a known location in our +issue tracker and understand what work is in progress, what’s up next, target +dates, and commitment dates. (We intentionally do not provide centralized +visibility into the backlog.) + +**Q: When do changes need to be communicated? Do changes need to be approved?** + +All changes should be passively communicated through updating the [product +roadmap](https://docs.google.com/document/d/1XehlyVYzyUP7jClMJB7NV-RyKyI4X14zkQ2N8Us4Q48/edit#heading=h.3yu1a6dm5wpq) +or, eventually, the issue tracker. Only some changes need to be actively +communicated to leadership and stakeholders. + +For WIP: + +- Dropped work: Must be communicated and approved +- Updated target date, has commitment date: Must be communicated and approved +- Updated target date, no commitment date: + - If the target was within the next month, must be communicated. + - If the target was further out, update, with active communication as needed +- Newly started work: Update, with active communication as needed. + +For Next queue work: + +- Dropped work: Must be communicated and approved +- Added work: Update, with active communication as needed +- Order changed: Update, with active communication as needed + +Beyond this, any work that is at risk, even if it doesn’t trigger any changes, +should be communicated to at least +[#epd-planning](https://sourcegraph.slack.com/archives/C04SCUER62C) or in a PFP +sync. + +**Q: When does eng scoping happen?** + +When work becomes WIP, before setting a target date, EPD should do a high level +assessment to ensure a high level of confidence in the target date. As work +progresses, teams should continue to refine target dates. + +Eng scoping is the difference between eyeballing a list of requirements and +hoping we can get them all done and having confidence that we can accomplish +what we want. And if we can’t, we want to know that ASAP so we can break it into +smaller [stepping +stones](https://medium.com/@jamesacowling/stepping-stones-not-milestones-e6be0073563f), +adjust dates, or cut scope. + +**Q: What are tips for effective quarterly check-ins?** + +A: Some tips for having an effective review: + +- Make sure the priorities for your work are clear – what’s Must Have (P0), Want To Have (P1) and Nice To Have (P2)? What could get cut? +- Make sure the customer (internal and/or external) impact is clear – if we do this work, what’s the value to the customer? +- Make sure the business impact is clear: how does this work help us achieve our strategic goals? +- In addition to ensuring that the EPD team is aligned before heading into the review, try to get as much alignment with execs ahead of time as possible. From 4eb179993d446efe969c09c30faebb85695a85d7 Mon Sep 17 00:00:00 2001 From: Robert Lin Date: Wed, 27 Mar 2024 16:38:28 +0900 Subject: [PATCH 4/4] managed-services: regenerate ops pages (add Cloud Relay) (#8780) Includes recent https://github.com/sourcegraph/managed-services/pull/655 --------- Co-authored-by: bobheadxi --- .../engineering/managed-services/cloud-ops.md | 4 +- .../managed-services/cloud-relay.md | 93 +++++++++++++++++++ .../managed-services/cody-analytics.md | 4 +- .../engineering/managed-services/entitler.md | 4 +- .../managed-services/gatekeeper.md | 4 +- .../engineering/managed-services/index.md | 5 +- .../managed-services/msp-testbed.md | 4 +- .../engineering/managed-services/pings.md | 4 +- .../managed-services/releaseregistry.md | 4 +- .../engineering/managed-services/sams.md | 4 +- .../managed-services/sourcegraph-accounts.md | 4 +- .../managed-services/support-integration.md | 4 +- .../managed-services/telemetry-gateway.md | 4 +- 13 files changed, 118 insertions(+), 24 deletions(-) create mode 100644 content/departments/engineering/managed-services/cloud-relay.md diff --git a/content/departments/engineering/managed-services/cloud-ops.md b/content/departments/engineering/managed-services/cloud-ops.md index e9857072ae43..222b496d6259 100644 --- a/content/departments/engineering/managed-services/cloud-ops.md +++ b/content/departments/engineering/managed-services/cloud-ops.md @@ -3,8 +3,8 @@ This document describes operational guidance for Cloud Ops Dashboard infrastructure. diff --git a/content/departments/engineering/managed-services/cloud-relay.md b/content/departments/engineering/managed-services/cloud-relay.md new file mode 100644 index 000000000000..a42254390032 --- /dev/null +++ b/content/departments/engineering/managed-services/cloud-relay.md @@ -0,0 +1,93 @@ +# Cloud Relay infrastructure operations + + + +This document describes operational guidance for Cloud Relay infrastructure. +This service is operated on the [Managed Services Platform (MSP)](../teams/core-services/managed-services/platform.md). + +> [!IMPORTANT] +> If this is your first time here, you must follow the [sourcegraph/managed-services 'Tooling setup' guide](https://github.com/sourcegraph/managed-services/blob/main/README.md) as well to clone the service definitions repository and set up the prerequisite tooling. + +If you need assistance with MSP infrastructure, reach out to the [Core Services](../teams/core-services/index.md) team in #discuss-core-services. + +## Service overview + +| PROPERTY | DETAILS | +| ------------ | -------------------------------------------------------------------------------------------------------------------- | +| Service ID | [`cloud-relay`](https://github.com/sourcegraph/managed-services/blob/main/services/cloud-relay/service.yaml) | +| Owners | **cloud** | +| Service kind | Cloud Run service | +| Environments | [prod](#prod) | +| Docker image | `us-central1-docker.pkg.dev/control-plane-5e9ee072/docker/cloud-relay` | +| Source code | [`https://github.com/sourcegraph/cloud-relay` - `.`](https://https://github.com/sourcegraph/cloud-relay/tree/HEAD/.) | + +## Environments + +### prod + +| PROPERTY | DETAILS | +| ------------------- | ---------------------------------------------------------------------------------------------------- | +| Project ID | [`cloud-relay-prod-bd4c`](https://console.cloud.google.com/run?project=cloud-relay-prod-bd4c) | +| Category | **internal** | +| Resources | | +| Slack notifications | [#alerts-cloud-relay-prod](https://sourcegraph.slack.com/archives/alerts-cloud-relay-prod) | +| Alerts | [GCP monitoring](https://console.cloud.google.com/monitoring/alerting?project=cloud-relay-prod-bd4c) | +| Errors | [Sentry `cloud-relay-prod`](https://sourcegraph.sentry.io/projects/cloud-relay-prod/) | +| Domain | [cloud-relay.sgdev.org](https://cloud-relay.sgdev.org) | +| Cloudflare WAF | ✅ | + +MSP infrastructure access needs to be requested using Entitle for time-bound privileges. + +| ACCESS | ENTITLE REQUEST TEMPLATE | +| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| GCP project read access | [Read-only Entitle request for the 'Internal Services' folder](https://app.entitle.io/request?data=eyJkdXJhdGlvbiI6IjEwODAwIiwianVzdGlmaWNhdGlvbiI6IkVOVEVSIEpVU1RJRklDQVRJT04gSEVSRSIsInJvbGVJZHMiOlt7ImlkIjoiNzg0M2MxYWYtYzU2MS00ZDMyLWE3ZTAtYjZkNjY0NDM4MzAzIiwidGhyb3VnaCI6Ijc4NDNjMWFmLWM1NjEtNGQzMi1hN2UwLWI2ZDY2NDQzODMwMyIsInR5cGUiOiJyb2xlIn1dfQ%3D%3D) | +| GCP project write access | [Write access Entitle request for the 'Internal Services' folder](https://app.entitle.io/request?data=eyJkdXJhdGlvbiI6IjEwODAwIiwianVzdGlmaWNhdGlvbiI6IkVOVEVSIEpVU1RJRklDQVRJT04gSEVSRSIsInJvbGVJZHMiOlt7ImlkIjoiZTEyYTJkZDktYzY1ZC00YzM0LTlmNDgtMzYzNTNkZmY0MDkyIiwidGhyb3VnaCI6ImUxMmEyZGQ5LWM2NWQtNGMzNC05ZjQ4LTM2MzUzZGZmNDA5MiIsInR5cGUiOiJyb2xlIn1dfQ%3D%3D) | + +For Terraform Cloud access, see [prod Terraform Cloud](#prod-terraform-cloud). + +#### prod Cloud Run + +The Cloud Relay prod service implementation is deployed on [Google Cloud Run](https://cloud.google.com/run). + +| PROPERTY | DETAILS | +| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Console | [Cloud Run service](https://console.cloud.google.com/run?project=cloud-relay-prod-bd4c) | +| Service logs | [GCP logging](https://console.cloud.google.com/logs/query;query=resource.type%20%3D%20%22cloud_run_revision%22%20-logName%3D~%22logs%2Frun.googleapis.com%252Frequests%22;summaryFields=jsonPayload%252FInstrumentationScope,jsonPayload%252FBody,jsonPayload%252FAttributes%252Ferror:false:32:end?project=cloud-relay-prod-bd4c) | +| Service traces | [Cloud Trace](https://console.cloud.google.com/traces/list?project=cloud-relay-prod-bd4c) | +| Service errors | [Sentry `cloud-relay-prod`](https://sourcegraph.sentry.io/projects/cloud-relay-prod/) | + +You can also use `sg msp` to quickly open a link to your service logs: + +```bash +sg msp logs cloud-relay prod +``` + +#### prod Terraform Cloud + +This service's configuration is defined in [`sourcegraph/managed-services/services/cloud-relay/service.yaml`](https://github.com/sourcegraph/managed-services/blob/main/services/cloud-relay/service.yaml), and `sg msp generate cloud-relay prod` generates the required infrastructure configuration for this environment in Terraform. +Terraform Cloud (TFC) workspaces specific to each service then provisions the required infrastructure from this configuration. +You may want to check your service environment's TFC workspaces if a Terraform apply fails (reported via GitHub commit status checks in the [`sourcegraph/managed-services`](https://github.com/sourcegraph/managed-services) repository, or in #alerts-msp-tfc). + +> [!NOTE] +> If you are looking for service logs, see the [prod Cloud Run](#prod-cloud-run) section instead. In general: +> +> - check service logs ([prod Cloud Run](#prod-cloud-run)) if your service has gone down or is misbehaving +> - check TFC workspaces for infrastructure provisioning or configuration issues + +To access this environment's Terraform Cloud workspaces, you will need to [log in to Terraform Cloud](https://app.terraform.io/app/sourcegraph) and then [request Entitle access to membership in the "Managed Services Platform Operator" TFC team](https://app.entitle.io/request?data=eyJkdXJhdGlvbiI6IjM2MDAiLCJqdXN0aWZpY2F0aW9uIjoiSlVTVElGSUNBVElPTiBIRVJFIiwicm9sZUlkcyI6W3siaWQiOiJiMzg3MzJjYy04OTUyLTQ2Y2QtYmIxZS1lZjI2ODUwNzIyNmIiLCJ0aHJvdWdoIjoiYjM4NzMyY2MtODk1Mi00NmNkLWJiMWUtZWYyNjg1MDcyMjZiIiwidHlwZSI6InJvbGUifV19). +The "Managed Services Platform Operator" team has access to all MSP TFC workspaces. + +> [!WARNING] +> You **must [log in to Terraform Cloud](https://app.terraform.io/app/sourcegraph) before making your Entitle request**. +> If you make your Entitle request, then log in, you will be removed from any team memberships granted through Entitle by Terraform Cloud's SSO implementation. + +The Terraform Cloud workspaces for this service environment are [grouped under the `msp-cloud-relay-prod` tag](https://app.terraform.io/app/sourcegraph/workspaces?tag=msp-cloud-relay-prod), or you can use: + +```bash +sg msp tfc view cloud-relay prod +``` diff --git a/content/departments/engineering/managed-services/cody-analytics.md b/content/departments/engineering/managed-services/cody-analytics.md index 233d8ceaa351..f0c6a78c435f 100644 --- a/content/departments/engineering/managed-services/cody-analytics.md +++ b/content/departments/engineering/managed-services/cody-analytics.md @@ -3,8 +3,8 @@ This document describes operational guidance for Cody Analytics infrastructure. diff --git a/content/departments/engineering/managed-services/entitler.md b/content/departments/engineering/managed-services/entitler.md index de64d0f50ff8..1e87431abee6 100644 --- a/content/departments/engineering/managed-services/entitler.md +++ b/content/departments/engineering/managed-services/entitler.md @@ -3,8 +3,8 @@ This document describes operational guidance for Entitler infrastructure. diff --git a/content/departments/engineering/managed-services/gatekeeper.md b/content/departments/engineering/managed-services/gatekeeper.md index d9e3f157217a..540f9953d0b2 100644 --- a/content/departments/engineering/managed-services/gatekeeper.md +++ b/content/departments/engineering/managed-services/gatekeeper.md @@ -3,8 +3,8 @@ This document describes operational guidance for Cody Gatekeeper infrastructure. diff --git a/content/departments/engineering/managed-services/index.md b/content/departments/engineering/managed-services/index.md index e68953b407a4..f682f8e079bb 100644 --- a/content/departments/engineering/managed-services/index.md +++ b/content/departments/engineering/managed-services/index.md @@ -3,8 +3,8 @@ These pages contain generated operational guidance for the infrastructure of [Managed Services Platform (MSP)](../teams/core-services/managed-services/platform.md) services. @@ -29,6 +29,7 @@ Managed Services Platform services owned by `Customer Support`: Managed Services Platform services owned by `cloud`: - [Cloud Ops Dashboard](./cloud-ops.md) +- [Cloud Relay](./cloud-relay.md) ## cody-plg diff --git a/content/departments/engineering/managed-services/msp-testbed.md b/content/departments/engineering/managed-services/msp-testbed.md index 0b1dff50d9a9..dd02c4823edb 100644 --- a/content/departments/engineering/managed-services/msp-testbed.md +++ b/content/departments/engineering/managed-services/msp-testbed.md @@ -3,8 +3,8 @@ This document describes operational guidance for MSP Testbed infrastructure. diff --git a/content/departments/engineering/managed-services/pings.md b/content/departments/engineering/managed-services/pings.md index 308f0f11e002..ead843f63c38 100644 --- a/content/departments/engineering/managed-services/pings.md +++ b/content/departments/engineering/managed-services/pings.md @@ -3,8 +3,8 @@ This document describes operational guidance for Pings Service infrastructure. diff --git a/content/departments/engineering/managed-services/releaseregistry.md b/content/departments/engineering/managed-services/releaseregistry.md index 88aff6d809c5..ad7b208abc40 100644 --- a/content/departments/engineering/managed-services/releaseregistry.md +++ b/content/departments/engineering/managed-services/releaseregistry.md @@ -3,8 +3,8 @@ This document describes operational guidance for Release Registry infrastructure. diff --git a/content/departments/engineering/managed-services/sams.md b/content/departments/engineering/managed-services/sams.md index d76413ee3ed4..73ce6ac7ebdd 100644 --- a/content/departments/engineering/managed-services/sams.md +++ b/content/departments/engineering/managed-services/sams.md @@ -3,8 +3,8 @@ This document describes operational guidance for Self-Serve Cody infrastructure. diff --git a/content/departments/engineering/managed-services/sourcegraph-accounts.md b/content/departments/engineering/managed-services/sourcegraph-accounts.md index 41c0669e922e..6411536d6e38 100644 --- a/content/departments/engineering/managed-services/sourcegraph-accounts.md +++ b/content/departments/engineering/managed-services/sourcegraph-accounts.md @@ -3,8 +3,8 @@ This document describes operational guidance for Sourcegraph Accounts infrastructure. diff --git a/content/departments/engineering/managed-services/support-integration.md b/content/departments/engineering/managed-services/support-integration.md index 8422a54062c5..39e16d6c7bf4 100644 --- a/content/departments/engineering/managed-services/support-integration.md +++ b/content/departments/engineering/managed-services/support-integration.md @@ -3,8 +3,8 @@ This document describes operational guidance for Support Integration infrastructure. diff --git a/content/departments/engineering/managed-services/telemetry-gateway.md b/content/departments/engineering/managed-services/telemetry-gateway.md index bd2f7ae9faed..386c40d2b7fd 100644 --- a/content/departments/engineering/managed-services/telemetry-gateway.md +++ b/content/departments/engineering/managed-services/telemetry-gateway.md @@ -3,8 +3,8 @@ This document describes operational guidance for Telemetry Gateway infrastructure.