스타트업에서의 프로덕션 지원은 인기가 없을 수 있어요. "빠르게 진행하고 문제를 해결하라"는 세상에서, 많은 것이 망가지고 당신은 빠르게 움직여야 합니다. 버그 보고서와 경고는 스트레스를 유발하며, 모든 것이 긴급하며, 고쳐야 할 문제가 빨리 그리고 허접하게 처리됩니다. 다음에 무슨 일이 일어날 지 아무도 모릅니다.

하지만 이렇게 스트레스 받을 필요는 없어요! 우리의 프로덕션 지원 목표는 제품을 만드는 것이 아니라 문제를 해결하는 것입니다. 우리가 솔루션을 빨리 제시하는 것은 급히 해결하는 것이 아닙니다: 고객 문제를 빠르게 해결하는 것입니다. 미래에 누가 일어날 지 모르면, 당신의 일은 미래를 예측하는 것이 아니라 다음 퍼즐을 풀어나가는 것입니다. 그리고 모든 것이 급하다면, 마감일은 중요하지 않아요.

"선"으로 프로덕션 지원을 디자인하는 것은 쉽지 않겠지만, 올바르게 수행되면, 프로덕션 지원은 광란의 무리가 아니라 강을 따라 보트를 타는 것과 같아질 거예요.

올바른 프로세스에 대한 포스트가 아닙니다

당신의 조직이 지원에 대해 대응하기 어려울 때는, 지원을 너무 넓게 또는 좁게 정의했을 수 있다는 것일 수도 있습니다. 우리는 레버나 조절기에 대해 깊이 파고들지 않겠지만, 여기에 좋은 접근 방식이 있고, 그 정의를 회전으로 운영화하는 깔끔한 방법이 있습니다.

우리는 이 간소화된 정의를 사용할 것입니다:

각 조직마다 긴급하고 중요한 사항으로 간주되는 것, 티켓 처리 담당자, 그리고 추적되고 처리되는 방식에 대한 약간 다른 요구 사항이 있을 것입니다. 세부 사항에 상관없이, 지원에 대한 문화가 건강한 시스템을 만들거나 망칠 수 있습니다.

“비정규 시간” 경보에 대한 주의: 우리가 제품 지원이 지속 가능해야 하는 방법에 대해 알아보기 전에 명확히 해 둬야 할 점이 있습니다. 비정규 시간 경보는 '젠'과는 아무런 연관이 없다는 점입니다. 이러한 상황이 계속 발생한다면 먼저 그 문제를 해결해야 합니다. 이 Datadog 기사는 시작하기에 훌륭한 자리입니다.

젠의 마음가짐

제품 지원에 대한 평안한 마음가짐은 일이 엉뚱한 방향으로 흘러갈 때 '왜'를 알고 있는 것을 의미합니다. 제가 기억하는 4가지 원칙은 다음과 같습니다:

버그 해결은 기술이다 (뜻: 목적지가 아니라 여정이 중요함)

디버깅을 능숙하게 하는 방법은 단 하나, 디버깅을 하는 것뿐입니다. 어려운 문제에 직면했을 때 관점을 잃기 쉽지만, 디버깅 과정 자체가 복합한 기술이라는 점을 명심해야 합니다. 세심한 추론, 다양한 맥락의 종합, 빈번한 커뮤니케이션, 그리고 깊은 무너지지 않도록 "부드러운 눈"이 필요합니다. 각 해결된 퍼즐은 툴킷에 더 많은 도구를 더해 디버깅 휠을 가속화합니다.

디버깅에 대한 불행한 진실은 일반적으로 무엇이 문제인지 알지 못하며 문제를 해결하는 데 얼마나 시간이 걸릴지 모른다는 것입니다. 소프트웨어 개발과는 달리 프로덕션 지원은 우아하고 튼튼한 것을 구축하기 위한 계획을 세우는 것이 아니라 한 번에 한 가지 문제를 해결하는 것입니다. 정체될 때, 결과적으로 해결해 나갈 것이고, 그 과정에서 더 나은 방법으로 발전해 나갈 기회를 가져야 합니다.

소유권은 자신이 개판으로 된 코드를 고치는 것을 의미합니다

프로덕션 지원은 각 개발자가 팀이 소유한 코드에 대해 실제로 배울 수 있는 훌륭한 기회입니다. 이는 "상자와 화살표" 버전만이 아닙니다: 디버거와 스택 추적은 모든 조건과 식의 세세한 부분으로 끌어들입니다. 프로덕션 지원에 시간을 들이는 것은 당신이 소유 영역에서의 전문가로 거듭나는 신속한 길입니다.

고치는 버그는 당신이 코드에 책임감을 가지도록 만듭니다. 중요한 버그는 모두가 정직하게 유지되도록 도와주며, 코드 테스트에 동기부여가 됩니다. 여기서 중요한 것은 마음가짐입니다: 문제를 해결하는 것은 도덕적인 실패가 아니라, 스타트업이 계속 평가해야 하는 "지금 품질" 대 "나중 품질"의 균형의 일부입니다.

불편한 작업을 자동화하세요

팀이 빠르게 움직일 때, 모든 모서리 케이스를 고려할 수는 없으며, 여전히 가치를 제공해야 합니다. 성숙한 팀은 회피하기 어려운 비용이 많이 드는 모서리 케이스가 해로운지 이해하고, 수동으로 해결하기 쉽도록 만듭니다. 수동 프로세스는 도덕적인 실패가 아닙니다. 항상 좋지 않은 소프트웨어 디자인의 신호도 아닙니다. 단지 디자인의 균형을 이루는 것뿐입니다.

그러나, 수동 프로세스는 지원 팀에게 압박감을 주고 비즈니스에 큰 부담이 될 수 있습니다. 잘 갖춰진 프로덕션 지원팀에서는 티켓 간의 소요시간이 있어야 합니다. 이 시간 중에는 자동화를 구축하고 오버헤드를 줄이는 데 일부 시간을 쏟아야 합니다. 이것은 강렬한 강이 내려가는 즐거운 길의 일부입니다: 지원 티켓을 처리하면서 툴을 개선할 시간을 찾아 에트로피를 천천히 꺾어내려가세요.

고객 질문에 대한 대응으로 운영이나 코드 변경으로 이어지지 않는 경우(상징적인 "설계대로 작동함" 해결 코드)에는 비슷한 방식을 취할 수 있습니다. 개선된 문서, 데이터나 상태를 노출하는 내부 관리 도구, 스크립트 등을 활용하여 이러한 오버헤드를 최소화하는 데 도움이 됩니다. 미래 엔지니어들은 동일한 결론에 도달하는 데 시간을 낭비해서는 안 됩니다.

지원팀은 정보를 효과적으로 흡수할 수 있는 최고의 장소입니다.

많은 회사들이 새 직원들을 위해 "일부 버그 수정"을 입사 대조 목록에 포함하는 이유가 있습니다. 새로운 개발자에게는 특히 경험 많은 동료가 신속히 배우도록 돕는 경우, 처음으로 지원 역할을 하는 것이 매우 유익합니다. 프로덕션 지원은 학습, 영향력 행사 및 제품 소유권을 확립하는 데 훨씬 더 나은 기회가 됩니다.

신입 엔지니어들이 회사 문화를 흡수하는 시기는 또한 첫 몇 주입니다. "작은 향상" 대신 프로덕션 지원을 향하는 접근 방식을 갖는 것은 장기적으로 회사에서 성공을 이루기 위한 기반을 다질 수 있습니다. 프로덕션 지원이 스트레스 받지 않을 때, 플라이휠이 빨리 돌아가고 엔지니어들이 더욱 빠르게 참여할 수 있습니다.

버그는 당신의 적이 아닙니다

많은 조직들이 '성실한' 운영 지원 교대를 즐길 여유가 없으며, 이를 달성하는 것은 마음가짐만으로는 충분하지 않습니다. 버그가 도덕적인 결점이 아님과 자동화가 끊임없이 발전하는 대상임을 깨닫게 되면, 운영 지원을 악몽으로 만드는 실직적인 장애요소에 집중할 수 있습니다.

시끄러운 경보: 운영 지원을 평온하게 만드는 가장 중요한 단계는 단연 시끄러운 경보를 해결하는 것입니다. "경고 피로"는 현실이며, 너무 많은 경보가 있다면 고치는 일에 대한 의욕을 잃기 쉽습니다. 경고의 이성적인 상태가 없으면, 운영 지원은 항상 스트레스와 어려움을 동반할 것입니다.

누적된 "부수적인 작업": 빠르게 움직이는 조직에게 수동 작업과 질문 응답이 당연하긴 하지만, 이러한 작업들이 누적되면 조직이 파묻히게 될 수 있습니다. 지원 부수적인 작업 감소를 위한 "큰 푸시"에 시간을 할당하는 것은 팀을 올바른 방향으로 이끌 수 있는 매우 효과적인 방법일 수 있습니다.

고립과 경시: 좋은 지원 문화를 형성하는 데 가장 중요한 것은 협업, 멘토십 및 공감의 문화입니다. 엔지니어들은 질문을 하고 전화를 걸고 업무 중에서 배울 수 있는 공간과 지원이 필요합니다. 팀원들의 지식과 지혜를 활용할 수 있게 되면, 문제 해결이 재미있고 쉬워집니다.

도전적인 문제에 대처할 때 실력만큼 중요한 것은 마인드셋입니다. 생산 지원 방식은 플라이휠입니다: 스트레스와 소음은 패닉을 유발하고, 집중과 목적은 적극적인 태도를 유발합니다. 시스템과 조직의 엄격한 제약 사항을 극복하는 동안, 정신적 접근을 전도하는 것도 기억해야 합니다. 팀이 생산 지원에서 편안해지면 문제를 신속히 해결하고 고객이 승리합니다.