Testing Microservices - Revision history

Yuliya at 20:14, 4 February 2023

2023-02-04T20:14:57Z

Yuliya at 20:14, 4 February 2023

2023-02-04T20:14:42Z

Yuliya at 20:12, 4 February 2023

2023-02-04T20:12:57Z

Yuliya at 20:11, 4 February 2023

2023-02-04T20:11:58Z

Yuliya at 20:11, 4 February 2023

2023-02-04T20:11:20Z

Yuliya at 20:05, 4 February 2023

2023-02-04T20:05:20Z

Yuliya at 19:38, 4 February 2023

2023-02-04T19:38:09Z

Yuliya at 19:25, 4 February 2023

2023-02-04T19:25:33Z

Yuliya: Created page with "Tools - - Splunk stack and hashi wrapper for monitoring - NOC (Network Ops Center) -"

2023-02-04T19:22:47Z

Created page with "Tools - - Splunk stack and hashi wrapper for monitoring - NOC (Network Ops Center) -"

New page

Tools
-
- Splunk stack and hashi wrapper for monitoring
- NOC (Network Ops Center) -

@@ Line 17: / Line 17: @@
 * When we need teams to update their services, "should" didn't help - teams need to do a lot of things they "need" to do. What worked for some folks - include this kind of work into a plan, and set up expectation with the company and leadership that engineering will spend 70% of time on features, and 30% on all kinds of "stuff comes up". Still takes time, but works. But the culture change needs to come from the top down.
 * So, what do you do when stuff still goes down in prod? There's an incident commander / coordinator / collator - finding who needs to roll back / roll forward whatever needs to be done, and then coordinating a post mortem, which everyone can join. Action items are separated into short-term, med-term, and long-term.
 * COE (correction of error) can become a cause of tension, who's responsible for fixing things? How do you ensure teams are motivated and enabled to spend time fixing their things?
 * A lot of engineers understand technical KPIs but not business KPIs. Helping developers see how their work affects actual business metrics proved helpful. And severity of the incident must depend on the business impact, not on the internal politics (i.e. trying to hide incidents under "p2" to not get on CEO's radar)
 * "If it's painful - do it more often" principle

← Older revision		Revision as of 20:14, 4 February 2023
Line 20:		Line 20:
	* COE (correction of error) can become a cause of tension, who's responsible for fixing things? How do you ensure teams are motivated and enabled to spend time fixing their things?		* COE (correction of error) can become a cause of tension, who's responsible for fixing things? How do you ensure teams are motivated and enabled to spend time fixing their things?
	* A lot of engineers understand technical KPIs but not business KPIs. Helping developers see how their work affects actual business metrics proved helpful. And severity of the incident must depend on the business impact, not on the internal politics (i.e. trying to hide incidents under "p2" to not get on CEO's radar)		* A lot of engineers understand technical KPIs but not business KPIs. Helping developers see how their work affects actual business metrics proved helpful. And severity of the incident must depend on the business impact, not on the internal politics (i.e. trying to hide incidents under "p2" to not get on CEO's radar)
		+	* "If it's painful - do it more often" principle

@@ Line 17: / Line 17: @@
 * When we need teams to update their services, "should" didn't help - teams need to do a lot of things they "need" to do. What worked for some folks - include this kind of work into a plan, and set up expectation with the company and leadership that engineering will spend 70% of time on features, and 30% on all kinds of "stuff comes up". Still takes time, but works. But the culture change needs to come from the top down.
 * So, what do you do when stuff still goes down in prod? There's an incident commander / coordinator / collator - finding who needs to roll back / roll forward whatever needs to be done, and then coordinating a post mortem, which everyone can join. Action items are separated into short-term, med-term, and long-term.
 * COE (correction of error) can become a cause of tension, who's responsible for fixing things? How do you ensure teams are motivated and enabled to spend time fixing their things?
 * A lot of engineers understand technical KPIs but not business KPIs. Helping developers see how their work affects actual business metrics proved helpful. And severity of the incident must depend on the business impact, not on the internal politics (i.e. trying to hide incidents under "p2" to not get on CEO's radar)

@@ Line 1: / Line 1: @@
-Conversation points
+Conversation notes
 * Splunk stack and hashi wrapper for monitoring
 * NOC (Network Ops Center) -

← Older revision		Revision as of 20:11, 4 February 2023
Line 17:		Line 17:
	* When we need teams to update their services, "should" didn't help - teams need to do a lot of things they "need" to do. What worked for some folks - include this kind of work into a plan, and set up expectation with the company and leadership that engineering will spend 70% of time on features, and 30% on all kinds of "stuff comes up". Still takes time, but works. But the culture change needs to come from the top down.		* When we need teams to update their services, "should" didn't help - teams need to do a lot of things they "need" to do. What worked for some folks - include this kind of work into a plan, and set up expectation with the company and leadership that engineering will spend 70% of time on features, and 30% on all kinds of "stuff comes up". Still takes time, but works. But the culture change needs to come from the top down.
	* So, what do you do when stuff still goes down in prod? There's an incident commander / coordinator / collator - finding who needs to roll back / roll forward whatever needs to be done, and then coordinating a post mortem, which everyone can join. Action items are separated into short-term, med-term, and long-term.		* So, what do you do when stuff still goes down in prod? There's an incident commander / coordinator / collator - finding who needs to roll back / roll forward whatever needs to be done, and then coordinating a post mortem, which everyone can join. Action items are separated into short-term, med-term, and long-term.
		+	* COE (correction of error) can become a cause of tension, who's responsible for fixing things? How do you ensure teams are motivated and enabled to spend time fixing their things?
		+	* A lot of engineers understand technical KPIs but not business KPIs. Helping developers see how their work affects actual business metrics proved helpful. And severity of the incident must depend on the business impact, not on the internal politics (i.e. trying to hide incidents under "p2" to not get on CEO's radar)

@@ Line 3: / Line 3: @@
 * NOC (Network Ops Center) -
 * New bank - common stack, clojure, AWS
-* Netflix also started with same stack, but it diverged assuming commonnality of contracts. But Netflix has fantastic monitoring practices
+* Netflix also started with same stack, but it diverged assuming commonality of contracts. But Netflix has fantastic monitoring practices