채팅 운영: 사람 없는 사람들

가까운 네트워크에 접속하세요. Other API Economy 에서 제공합니다.

최근 DevOps 커뮤니티에서는 문화에 더 중점을 두는 방향으로 전환이 이루어지고 있습니다. 이는 보다 개방적이고 협력적인 교차 IT 환경으로의 문화적 변화 없이는 DevOps의 많은 이점을 완전히 실현할 수 없기 때문일 가능성이 높습니다. 폐쇄적이고 "알아야 할" 정보 공유는 우리가 애정을 담아 "IT"라고 부르는 각 운영 도메인에 고유한 부족 지식을 둘러싼 방어 타워처럼 서 있는 사일로로 이어집니다.

하지만 이를 분해하는 것은 고통스러울 수 있습니다. 그리고 어색하죠. 그리고 엄청나게 어렵죠. 우리는 거의 모든 IT 종사자의 "반사회적" 성격에 대해 농담을 하고 그 풍자화를 비웃을 수 있지만, 현실은 대부분의 전설과 동화와 마찬가지로 그러한 원형이 여전히 그 분야의 많은 사람들을 특징짓는 실제 행동과 특성에서 생겨났다는 것입니다.

저는 마이어스-브릭스 유형 중 INTJ 입니다. 언제나요. 네, "건축가"입니다. 저는 통찰력 스펙트럼에 있는 개혁 관찰자입니다. 통찰력 스펙트럼은 실제로 마이어스-브릭스보다 더 정확하다고 주장하는 지나치게 이상화된 융의 테스트일 뿐입니다. 어느 쪽이든 저는 꽤 내성적인 사람이에요. 오늘날 연구자들은 인구의 거의 50%가 내성적인 사람이라고 추정합니다. 그리고 제가 그랬던 것처럼 그들 중 많은 사람이 IT 분야로 진출했고, 이해하기 힘든 외향적인 사람들은 마케팅이나 관리 직책으로 옮겨갔다는 사실에 놀라지 않으실 겁니다.

내성적인 사람들은 사람들과 어울리는 것을 좋아하지 않습니다. 요즘 아이들은 이런 것을 사람들과의 상호작용이라고 부릅니다. 사실은 당신이 아니라 우리 때문입니다. 우리는 외향적인 사람들과는 다르게 정보와 데이터를 처리하고, 너무 많은 적극적인 상호작용이 압도적이라고 여깁니다. 우리는 사람들을 만날 수 있지만 지쳐요. 우리는 답변하기 전에 문자 메시지와 생각할 시간을 선호합니다. 그렇기 때문에 우리는 디지털 시대에도 꽤 잘 해내고 있습니다. 디지털 시대에 우리의 의사소통은 대부분 거리를 두고 문자를 통해 이루어집니다. 여러분이 우리를 디지털 형태로만 알고 있다면, 우리를 외향적인 사람으로 착각할 수도 있을 겁니다.

DevOps에 필요한 문화적 변화의 전제를 고려한다면 바로 갈등이 있다는 것을 알게 될 것입니다. 공유와 소통은 DevOps의 두 가지 중요한 구성 요소이며, 이는 내성적인 사람들을 모아서 사람뿐만 아니라 사람을 효과적으로 배치하는 것을 의미합니다. 즉, "사람 없는 사람"을 찾는 것은 무지개 끝에서 금광을 찾는 것과 같다는 뜻이다.

ChatOps가 바로 그 보물 창고일 수도 있겠어요.

채팅 운영: 사람 없는 사람들

ChatOps란 무엇일까요? 제이슨 핸드ChatOps 분야의 최고 전문가 중 한 명인 우리에게 간결한 정의를 준다: "ChatOps를 공유 명령줄이라고 생각하세요."

물론 그 이상이지만 가장 기본적인 면에서 이것은 시작하기에 아주 좋은 곳입니다.

HipChat 과 Slack 과 같은 도구는 기존의 IM 시스템처럼 1:1 소통을 위해 설계되지 않았습니다. 물론 가능합니다. 하지만 이러한 현대적 커뮤니케이션 플랫폼의 진정한 힘은 정보와 최신 소식을 관심이 있는 조직 내의 모든 사람과 즉시 공유할 수 있는 개방적인 커뮤니케이션 환경을 구축하는 것입니다. 잠복하는 것이 장려되는 이유는 지속적인 대화가 아니라 정보를 얻고 쉽게 접근할 수 있느냐가 중요하기 때문입니다.

채널(예: #IRC)은 신호 대 잡음 비율을 제어하는 수단을 제공하며, 누가 언제 무엇을 했는지에 대한 명확한 감사 추적을 제공합니다. 이러한 도구는 채팅 클라이언트 이상의 기능을 통해 이를 달성합니다. API를 통해 기능을 확장하여 사람뿐만 아니라 시스템과도 양방향 통신을 제공하는 플랫폼입니다. 즉, 인프라 구성 요소에서 알림을 전달할 수 있는 #알림 채널을 추가할 수 있다는 의미입니다.

비교적 쉽게, Slack용 "앱"을 빌드하여 API를 통해 정보를 쿼리하고 반환할 수 있습니다. 아마도 스위치일 수도 있고, 로드 밸런서일 수도 있고, 지역 날씨일 수도 있습니다. 무엇이든 이러한 도구 내에서 자동으로 작업을 실행하는 명령을 호출할 수 있습니다. 그리고 당신은 알 필요가 있거나 알면 도움이 될 수 있는 모든 사람 없이도 기도와 결과를 공유할 수 있습니다. 그런 다음 수행한 작업에 따라 작업을 문서화하고 다른 사람이 무슨 일이 일어나고 있는지 이해할 수 있는 흔적을 남깁니다. 모니터링 시스템의 상태 업데이트, 헬프 데스크의 새로운 티켓, 서버가 다운되어 더 이상 사용할 수 없다는 메모. API를 통해 전달할 수 있는 것들은 거의 모두 다른 사람들과 공유할 수 있습니다. 실제로 사람을 만나지 않고도 말이죠.

이 프로세스는 IT의 다른 영역(개발 포함)에 도움이 되는 멘토링, 교육 및 트라이브 지식 공개를 위한 풍부한 기회를 제공합니다. 사람들로 가득 찬 방에 모여 앉거나, 눈이 빛나는 신입 엔지니어를 대상으로 훈련을 실시하지 않고도 대규모로 공유하는 것입니다. 또한 이는 "네트워크"에서 DevOps 접근 방식을 성공적으로 도입하는 데 필요한 문화적 변화를 가능하게 하는 몇 안 되는 도구 중 하나이기도 합니다.

그리고 우리는 그것을 채택해야 합니다. 아직도 조심스러우시다면 Atlassian과 xMatters가 2017 DevOps 성숙도 설문 조사 에서 제기한 다음 질문을 고려해 보세요.

저자는 자신의 데이터를 기반으로 각자의 가설을 가지고 있지만, 저는 배포를 위해 릴리스된 애플리케이션이 프로덕션에 사용되는 애플리케이션과 동일하지 않다는 것을 상기시켜주는 구성의 오류 에 주로 기반한 또 다른 가설을 가지고 있습니다. 앱 서비스를 삽입하고 네트워크와 상호 작용하면 구성이 변경됩니다. 실제 운영 환경과 정확히 동일한 복제본에서 수행하지 않는 한 해당 애플리케이션의 검토는 더 이상 완전하게 적용되지 않습니다.

더 나쁜 점은, 거의 1/3의 회사에서 고객이 서비스 중단을 알릴 때까지 이러한 문제를 발견하지 못한다는 것입니다. 이는 개발과 IT 부문에서 정보를 공유하는 방식 때문일 수 있습니다. 29%는 특별히 요청이 있을 때만 팀 간에 정보를 공유한다고 답했습니다. "기술적인 정보, 목표, 계획 및 결과를 제공하여 모든 사람에게 정보를 공개"하는 사람은 16.8%에 불과합니다. 

운영 환경에서 앱의 동작에 대한 고유한 정보가 없으면 문제의 원인을 파악하기 어려운 경우가 많고, 더욱이 문제의 근원을 파악하는 것도 어렵습니다. "내 컴퓨터에서는 작동합니다"는 개발자가 환경 정보 부족으로 인해 발생하는 나쁜 동작을 복제할 수 없다는 좌절감에서 비롯된 방어적 주문입니다.

모든 네트워크 관련 작업을 자동화 할 생각은 없더라도 ChatOps는 IT와 개발 간의 커뮤니케이션 라인을 열고 문제에 대한 더 큰 통찰력을 제공하여 MTTR(평균 해결 시간)을 단축하는 데 좋은 방법입니다.  이는 엔지니어에게 방해가 되거나 세세한 부분까지 관리하지 않고도 "네트워크에서" 무슨 일이 일어나고 있는지에 대한 보다 포괄적인 관점을 제공하는 수단입니다. 이것은 내성적인 사람들에게 사람 없이 사람들과 소통할 수 있는 방법을 제공하며, 더 자주, 더 철저하게, 그리고 더 열정적으로 공유하도록 장려합니다.

ChatOps를 처음 사용하는 분이라면 Jason Hand의 전자책 "ChatOps for Dummies "를 꼭 읽어보시길 추천합니다. 이메일을 포기해야 하지만 그만한 가치가 있습니다. 

여기서 계속 지켜봐 주시기 바랍니다. 앞으로 ChatOps에 관한 내용이 더 많아질 거라고 보장할 수 있어요.