15년간의 소프트웨어 사고 관리 경험을 통해 얻은 12가지 정도의 교훈

소프트웨어 엔지니어로서 사고를 처리하는 것은 짜증나는 일입니다. 토요일 오전 3시에 통화 페이지를 받으시겠습니까? 그것은 두려움을 불러일으키고, 영혼을 빨아들이고, 완전히 혐오스러운 에피소드가 될 수 있습니다. 직장에서 이런 일이 자주 발생한다면 말 그대로 PTSD를 유발할 수 있습니다.

불행하게도 이것은 소프트웨어 시대정신의 일부이자 핵심입니다. 오히려 이것이 실제 엔지니어링이 완성되는 불길입니다. 이러한 사고는 강화된 시스템을 설계하는 방법과 많은 경우 그렇게 하지 않는 방법을 알려줍니다.

이 문서에서는 소프트웨어 사고를 처리하는 방법의 두 가지 측면을 설명합니다.

• 🛠️ 이러한 경험을 예방하고 교훈을 얻기 위해 소프트웨어 플랫폼과 팀에 주입해야 하는 관행입니다.

• 🧘 사람이 가져야 할 태도는 회복력을 갖고 상처를 입지 않을 뿐만 아니라 겪은 것보다 더 많은 경험을 통해 이러한 경험에서 벗어나야 합니다.

우리가 다룰 주제는 —

1. 시스템을 최대한 자동화하세요.
2. 선행 지표와 후행 지표 추적
3. "실행 가능한" 경고는 자명해야 합니다.
4. 명확한 콜 체인 및 에스컬레이션 경로 설정
5. 중요한 결정을 내릴 수 있도록 최전선의 역량을 강화하세요
6. 모든 사건이 동일하게 생성되는 것은 아닙니다.
7. 먼저 해결하고 나중에 질문하세요.
8. 한 사람이 담당자인지 확인하세요.
9. 명확하고 자주 의사소통하기
10. 무책임한 사후검토가 중요하다
11. 사후 부검에 대한 후속 조치가 중요합니다.
12. MTTD가 낮으면 사고는 나쁘지 않습니다.
13. 유머는 훌륭한 이퀄라이저이다

몇 가지 세부 사항을 알아보겠습니다!

가능한 한 시스템을 자동화하세요

고객을 통해 또는 사건이 시작된 지 며칠 또는 몇 주 동안 심각한 회계 불일치를 통해 알게 된 사건의 수를 최소화하고 싶습니다 . "자동화"는 엔지니어링에서 과도하게 사용되는 단어이지만 이는 신호 대 잡음비의 올바른 균형을 찾고 사용자와 팀이 사람의 개입 없이 경고를 받을 수 있도록 보장하려는 영역 중 하나입니다.

선택할 것이 너무 많으면 최고 수준으로 이동하세요. 선택할 수 있는 가장 높은 수준의 측정항목은 무엇입니까? 구성 요소 시스템이 예상대로 작동하지 않으면 표준에서 벗어날 수 있습니까? 이는 플랫폼(전자상거래, 금융 또는 $ 기반 플랫폼의 경우)을 통해 흐르는 수익을 추적하거나(소셜 미디어 플랫폼의 경우) 현재 활성 사용자 수를 추적할 수 있습니다.

숫자가 표준 편차 한두 개 정도 떨어지거나 떨어지면 즉시 개발팀에 알리세요. 비즈니스 동향이나 핵심 사용자 경험에 첫 번째(또는 가장 중요한) 경고에 초점을 맞추는 것은 모니터링할 수 있는 훌륭한 지표가 될 것입니다. 시스템이 더욱 정교해지고 시스템을 더 잘 이해하게 되면 관찰 가능성의 관점에서 스택 아래로 더 깊이 들어갈 수 있습니다.

선행 지표와 후행 지표 추적

선행지표는 본질적으로 예측적이며 곧 발생할 문제를 지적할 가능성이 있는 반면, 후행지표는 사후적이고 문제가 잘 진행된 후의 여파를 나타냅니다. 후행 지표(예: "급락하는 주문 수") 외에 선행 지표(예: 감소하기 시작하는 "세션 기간")를 활용하면 다음과 같은 상황을 피할 수 있습니다. 꽤 재앙적이다.

"실행 가능한" 경고는 자명해야 합니다.

경고는 해고되었을 때 취해야 할 다음 단계가 무엇인지 명확히 알 수 있도록 자명해야 합니다. 문제의 심각도를 확인하든, 사건을 해결하든, 문제를 해결하든 경고와 관련된 세부 정보가 충분해야 합니다. 경고로 무엇을 할지 결정하기 위해 많은 사전 논의가 필요하지 않은지 확인하고 싶습니다.

경고 자체의 내용에 이러한 세부 정보를 추가할 수 있으며, 내용이 상당히 자세한 경우 이러한 유형의 문제에 대해 팀에서 유지 관리하는 런북에 연결할 수 있습니다.

명확한 콜 체인 및 에스컬레이션 경로 설정

서비스 소유권, 시간대 인식 등과 같은 사항을 기반으로 경고가 라우팅되는 대상을 포함하여 경고가 실행될 때 어떤 일이 발생하는지에 대한 명확한 개요를 갖는 것은 신속한 대응을 보장하는 데 중요합니다. 즉각적인 1차 방어선 외에도 사고 대응자가 사고를 어떻게, 누구에게 에스컬레이션할 수 있는지 명확하게 하는 것도 똑같이 중요합니다.

문제가 한 사람이 처리할 수 있는 것보다 복잡하거나 범위가 훨씬 더 큰 경우에는 부서 간 이해관계자뿐만 아니라 더 많은 고위 직원(또는 팀의 여러 사람)을 참여시켜야 할 수도 있습니다. 도구(예: PagerDuty, OpsGenie) 또는 명확한 문서(실행 도서, 위키 페이지, 저장소 README)를 통해 모든 것에 쉽게 액세스할 수 있도록 만드는 것이 재앙적인 사건이냐, 아무 것도 없는 것의 차이일 수 있습니다.

중요한 결정을 내릴 수 있도록 최전선의 역량을 강화하세요

명확한 에스컬레이션 경로가 필요하지만 이것이 기본 응답이 되는 것을 원하지 않습니다. 고위 경영진과 상의할 필요 없이 최초 대응자가 출혈을 막기 위한 실제 조치를 취하거나 교정을 위한 현장 결정을 내릴 수 있도록 권한을 부여해야 합니다. 이는 낙진을 제한하는 측면에서 회사뿐만 아니라 중요한 결정을 내릴 수 있다는 신뢰를 받는 높은 책임을 맡은 직원에게도 좋습니다. 관료적인 절차를 줄이고 개인의 선택 의지를 강화하십시오.

모든 사고가 동일하게 생성되는 것은 아닙니다

콜 체인 및 에스컬레이션 경로와 함께 중요한 또 다른 보조 요소는 사고 우선 순위 척도입니다. 이는 일반적으로 최초 대응자 또는 사고 지휘관을 위한 빠른 참조입니다. 다양한 수준의 대응이 필요할 수 있으므로 사고의 심각도를 신속하게 파악하고 그에 따라 라벨을 붙이는 데 도움이 됩니다.

대응 담당자가 허위 경보를 방지하려면 심각한 사고(예: 시스템 중단 또는 재무 데이터 손상)와 사소한 문제(예: 색상 팔레트 결함)를 구별하는 것이 필수적입니다. 또한 팀의 대응이 효과적이고 집중적으로 유지되도록 보장합니다.

먼저 해결하고 나중에 질문하세요.

의심의 여지 없이 가장 중요한 일 중 하나는 사건을 최대한 빨리 해결하는 것입니다. 사건이 진행되는 동안 왜 어떤 일이 일어났는지, 어떻게 예방할 수 있었는지 철학적으로 생각하는 데 시간을 보내고 싶지 않습니다. 사후 부검을 위해 예약할 수 있습니다. 지금은 사건 해결에만 집중하고 나중에 어려운 질문을 하세요.

한 사람이 담당하는지 확인하십시오.

때로는 사건이 너무 커질 수도 있습니다. 그들은 너무 많은 서비스를 다루거나, 여러 비즈니스 영역에 걸쳐 있거나, 수익이나 평판 측면에서 정말 큰 영향을 미칩니다. 이때 전체 사건에 대해 "교통경찰"을 맡을 한 사람을 임명하는 것이 절대적으로 중요합니다. Place Exchange에서는 복잡한 사고 대응에 대한 교육을 받은 소규모 그룹인 '사고 지휘관'을 구성했습니다.

이런 종류의 역할을 갖는 것이 매우 중요한 이유는 여러 당사자가 관련된 경우 누군가가 트래픽을 지시해야 하기 때문입니다. 종종 엔지니어들은 문제의 복잡성에 대해 토끼굴 속으로 들어가거나 문제 해결 방법을 이해하려고 노력할 것입니다.

사고 지휘관의 역할은 신속한 사고 해결에 그룹의 초점을 맞추는 것입니다. 그들은 모든 사람이 행동에 대한 편견을 갖고 있는지 확인하고 측면 조사도 중요할 수 있지만 앞으로의 추진력을 보장하는 것이 훨씬 더 중요합니다. 또한 내부 및 외부 이해관계자 및 파트너와 명확하고 지속적인 의사소통이 이루어지도록 하는 책임도 있습니다.

사고 지휘관은 일반적으로 Slack 회의 또는 Google Meet 회의와 같은 동기식 음성 커뮤니케이션을 시작합니다. 이를 통해 사건 해결에 중요한 사람들이 지속적으로 연락할 수 있습니다. 사람들이 채팅을 사용하여 비동기적으로 문제를 해결하도록 허용하는 것과 비교하면 이 작은 일이 얼마나 효과적인지 놀랍습니다.

사고 지휘관은 또한 완료해야 하는 작업에 대한 명확한 위임이 있는지 확인하고 해당 작업에 대한 대응이나 결과를 반환받을 책임이 있는지 확인하는 책임도 있습니다.

두 사람에게 말에게 먹이를 달라고 하면 말이 죽는다는 말이 있다. 사고지휘관은 이러한 일이 발생하는 것을 방지하고 궁극적으로 사고의 신속한 해결을 책임집니다.

명확하고 자주 의사소통하기

사람들은 팀이 사건 해결을 위해 어떻게 열심히 노력하고 있는지 계속 알면 자신이 좋아하는 앱이나 소프트웨어를 용서하는 경우가 많습니다. 당신이 사건에 대해 완전히 통제할 수 없다고 느끼거나 당신과 당신의 팀이 그것에 대해 당혹감을 느끼기 때문에 상황을 숨기려고 노력하는 것은 의사소통이 외부로 흐르는 것을 막을 이유가 되지 않습니다.

의사소통이 내부 및 외부 파트너 모두에게 간결하고 빈번하며 투명하게 이루어지도록 하십시오. 그렇게 하면 호의를 구축하는 데 도움이 됩니다.

비난 없는 사후 부검이 중요합니다

사후 부검이나 사건 사후 회고는 학습 문화를 구축하는 데 중요하며, 절대로 비난할 여지가 없어야 합니다. 사람이 아닌 과정을 비판하십시오. 이 일을 일으킨 사람보다 자신을 더 힘들게 하는 사람은 없으며, 공개적으로 그들을 채찍질해도 얻을 수 있는 것은 없습니다. 오히려 모든 연구에 따르면 이렇게 하면 실제로 손해를 본다고 합니다. Etsy 직원은 이에 대해 훨씬 더 잘 설명하므로 자세히 알아보려면 https://www.etsy.com/codeascraft/blameless-postmortems를 읽어보세요.

사후 부검에 대한 후속 조치가 중요합니다

사후 분석을 자체적으로 수행하는 것은 이러한 사건으로부터 배울 수 있는 인식과 피드백 루프를 구축하는 데 중요하지만, 향후 이러한 일이 발생하지 않도록 논의되는 조치 항목이 더 중요할 수 있습니다. 그룹이 시스템에서 일련의 공백이나 취약점을 식별한 경우 동일한 문제가 다시 발생하지 않도록 적시에 이를 해결하는 데 집중하고 주의를 기울이는 것이 매우 중요합니다.

사고 발생을 방지하는 것은 어렵고 일반적으로 비즈니스 및 고객과의 대화가 힘든 부분입니다. 그러나 동일한 사건이 계속해서 발생한다면 방어하기가 훨씬 더 어려워지고 팀의 건강과 기술에 심각한 문제가 있음을 나타냅니다.

MTTD가 낮으면 사고는 나쁘지 않습니다.

모두가 그것을 얻습니다. 심지어 사업가들도 그것을 이해합니다. 소프트웨어 구축은 어렵고 모든 소프트웨어에 수백, 수천 개의 종속성이 있고 단층선이 깨질 수 있는 세상에서는 예측이 불가능합니다. 똥이 팬을 때릴 것이고 괜찮습니다. 사건이 발생하는 것을 막을 수는 없습니다. 그러나 실제로 도움이 되는 것은 사고에 대한 MTTD가 매우 낮은지 확인하는 것입니다.

MTTD(평균 탐지 시간)는 조직이 사고 또는 보안 위협을 식별하는 데 걸리는 평균 시간을 측정하는 핵심 성과 지표(KPI)입니다. 비즈니스 영역, 영향의 심각도 등을 고려할 때 일반화하기는 어렵지만 MTTD를 몇 초에서 몇 분으로 줄일 수 있다면 말보다 사고의 영향을 크게 줄일 수 있을 것입니다. 몇 시간에서 며칠까지였습니다(불행히도 전적으로 가능한 몇 주 또는 몇 달은 물론이고).

유머는 순간의 고통을 덜어줍니다

이 모든 것이 너무 심각합니다! 돈이 사라지고 있어요! 황당한 경험을 하신 고객님! 하지만 그 와중에도 유머 감각을 갖는 것이 중요하다는 사실을 깨달았습니다. 우리는 이 과정에서 모든 사람이 인간이며 다양한 정도의 스트레스를 겪고 있다는 사실을 잊어서는 안됩니다. 적절한 시점에 유머를 주입하면 그러한 압박감을 어느 정도 완화하는 데 도움이 됩니다.

이는 팀이 지옥의 섬에 있는 것이 아니라 함께 있는 것처럼 느끼게 하는 동지애를 형성합니다.

그것은 마무리입니다. 읽어 주셔서 감사합니다!

⭐ 이런 유형의 콘텐츠가 마음에 드신다면 저를 팔로우하시거나 https://a1engineering.substack.com/subscribe 를 구독해 주세요! ⭐

Unsplash의 Julien L 특집 사진