Microsoft가 DevOps를 사용하여 신뢰할 수 있는 시스템을 운영하는 방법

Microsoft는 상용 인터넷의 초기부터 복잡한 온라인 플랫폼을 운영해 왔습니다. 그 과정에서 시스템을 사용 가능하고, 건강하고, 안전하게 유지하기 위해 상당한 일련의 사례를 발전시켰습니다. 이러한 관행은 라이브 사이트 문화를 달성하고 개선하기 기본 더 큰 이니셔티브의 일부입니다.

라이브 사이트 문화

라이브 사이트 문화는 다른 모든 항목보다 라이브 사이트의 환경과 안정성을 우선시하는 조직의 초점입니다. 결국, 고객은 클라우드 및 인터넷 기반 서비스를 통해 요즘 서비스 공급자 간에 매우 쉽게 이동할 수 있으므로 고객 신뢰의 중요성을 크게 증폭시킬 수 있습니다. 라이브 사이트는 항상 사용할 수 있어야 하며 고객에게 약속대로 수행되어야 합니다.

성공적인 라이브 사이트 문화에 기여하는 다양한 요소가 있습니다.

먼저 라이브 사이트

라이브 사이트 환경을 최우선으로 두는 것은 성공적인 플랫폼에 필수적입니다. 팀은 새로운 빛나는 기능에 모든 초점을 맞추고 사용자에게 해당 기능을 제공하는 방법을 무시할 수 없습니다. Microsoft는 고객이 중단 없는 플랫폼 액세스를 즐길 수 있도록 하는 안전한 배포 방법을 사용합니다. 이는 가동 중지 시간 없이 버전이 지정된 서비스 업데이트를 릴리스할 때 특히 복잡해질 수 있습니다.

기능 플래그를 통한 노출 제어

링과 스테이지를 통해 배포하고 기능 플래그로 노출을 제어할 때 프로덕션에서 문제가 발생하는 경우도 있습니다. 우리의 모든 자동화 및 리뷰에도 불구하고, 상황은 때때로 여전히 발생합니다. 그들이 말했듯이, 생산과 같은 곳은 없습니다!

일반적으로 상태 모니터링 및 원격 분석은 문제가 발생할 때 경고합니다. 개발자는 분기 main를 만들고 수정한 다음 끌어오기 요청으로 가져올 main수 있습니다. 동일한 일반 워크플로를 유지한다는 것은 개발자가 다른 코드 변경을 위해 컨텍스트 전환 또는 다른 프로세스를 학습할 필요가 없다는 것을 의미합니다.

핫픽스 배포를 해결하려면 릴리스 분기로 변경 내용을 선택해야 하는 한 단계가 더 필요합니다. 평일 아침에 현재 릴리스 분기에서 핫픽스 배포를 실행하지만 긴급 수정을 위해 요청 시 이 작업을 수행할 수도 있습니다. 이 수정 사항은 실제로 릴리스 분기에서 먼저 프로덕션에 도달합니다. 하지만 먼저 개발 main 했으므로 새 릴리스 분기가 만들어 main질 때 다음 스프린트가 회귀되지 않는다는 것을 알고 있습니다.

온-프레미스 제품의 릴리스는 배포 링과 스테이지가 없더라도 거의 동일합니다. 또한 다양한 구성 및 데이터 셰이프에 대해 더 많은 수동 테스트를 수행하므로 릴리스 분기를 절단하고 제품을 고객의 손에 넣는 것 사이에는 더 긴 꼬리가 있습니다.

보안은 개인적으로 수행해야 합니다.

취약성을 실제 및 개인으로 만드는 데 중점을 두는 것이 중요합니다. 이렇게 하면 사람들이 정말로 신경을 쓰게 됩니다. 또한 코드에서든 아니든 시스템 전체에서 보안 위험을 찾고 해결하기 위해 전쟁 게임을 광범위하게 사용합니다. 빨간색 팀이 대화 상자를 거꾸로 돌려 코드에 들어갔다는 것을 보여줄 수 있는 경우 코드 소유자 문제를 해결하고 다른 곳에서도 다시 발생하지 않도록 동기를 부여합니다. 이러한 종류의 경쟁은 잠재적인 XSS 위험에 대한 정적 분석 경고보다 훨씬 더 현실적이고 개인적입니다. 우리는 전쟁 게임 및 기타 보안 연습을 통해 이러한 종류의 문화와 역동적 인 문화를 만듭니다. 사람 서로의 코드를 해킹하거나 시도를 차단 할 수있는 자부심을 가지고 있습니다. 이렇게 하면 보안 코드 문화권이 생성됩니다.

모든 공격 벡터를 계획할 수는 없지만, 우리가 할 수 있는 일은 위반이 있을 것이라고 가정하고 해당 위반에 얼마나 빨리 대응할 수 있는지 계획하는 것입니다. 우리 팀을 위해 많은 보안 작업이 진행되었습니다.

마지막으로, 인간은 실수를 합니다. 때로는 지연되고 파일 공유에 암호 저장과 같은 작업을 수행합니다. 우리는 그들에게 말하지 않을 수 있으며 보안 교육에 보낼 수 있으며 모든 종류의 다른 일을 할 수 있습니다. 대부분의 사람들은 학습하지만 시스템을 중단하는 데는 한 사람만 걸립니다. 당신은 모범 사례의 목록의 모든 종류를 가질 수 있지만, 당신이 진짜하지 않는 한, 당신은 사람들이 실수를 할 거라고 가정해야합니다. 이를 위해서는 중요한 프로세스를 따르기 위해 특정 수준의 감독이 필요합니다.

엔지니어링은 ops 파트너 이상입니다.

우리는 라이브 사이트를 엔지니어링 팀의 책임에서 중요한 부분으로 만들기 위해 일찍부터 배웠습니다. 과거에 한 사람이 무언가를 배포하고, 주말에 떠나고, 월요일에 돌아와 고객 지원 및 운영 팀이 주말 내내 다루고 있던 900개의 고객 문제를 찾을 수 있었기 때문에 이는 우리에게 큰 일이었습니다. 엔지니어링은 라이브 사이트 문제에 대한 가격을 지불하는 것이 중요합니다. 그렇지 않으면 이러한 문제를 방지하는 시스템을 빌드할 인센티브가 없습니다. 당신이 파산 뭔가를 해결하기 위해 오전 2시에 전화를받을 때, 당신은 기억.

이러한 책임을 발전시켰을 때 라이브 사이트는 팀 전체의 진언이 된 가장 중요한 일 입니다. 그것은 그들이 지금 가지고있는 고객 경험이며, 그것은 단지 세금이 아닙니다. 그것은 실제로 사람들이 우리에게 의지하고 우리는 그것에 자부심을 가지고 뭔가. 그것은 우리의 제품의 차별화 기능이 될 필요가있다.

프로덕션 원격 분석은 서비스의 하트비트입니다.

거의 모든 것이 잘못될 수 있는 빠르게 진행되는 세상에서 살아남기 위해서는 훌륭한 경고 시스템이 필요합니다. 실행 불가능한 경고, 중복 경고 또는 압도적인 경고 볼륨으로 모든 경고를 무시합니다. 너무 많은 경고를 쉽게 만들 수 있으므로 이 프로세스는 실제로 간단한 질문 으로 증류합니다. 이 경고가 실행 가능합니까? 이렇게 하면 올바른 고객 문제에 참여하고 가능한 한 빨리 처리할 수 있습니다.

엔지니어링 팀이 실행 가능한 경고에 집중하면서, 특히 한밤중에 발생하는 많은 문제가 적어도 일시적으로 비슷한 수정을 하는 경향이 있음을 발견했습니다. 이로 인해 장애 조치(failover)와 자가 복구에 더 나은 시스템에 집중하게 됩니다. 이제 문제가 발생하고, 경고를 발생시키고, 엔지니어링 팀이 아침까지 기다렸다가 수정할 수 있을 만큼 충분히 문제를 해결합니다. 엔지니어링 팀이 밤에 다른 사람들을 유지하는 비트를 밀어 냈다면 이런 일은 일어나지 않았을 것입니다. 이제 기능 속도뿐만 아니라 엔지니어링 개선 속도의 일부로 이러한 개선 사항의 균형을 맞추기 위해 노력합니다.

요약

라이브 사이트 문화를 채택하면 Microsoft에서 소프트웨어를 빌드하고 제공하는 방식에 영향을 줍니다. 엔지니어링 팀을 보안 및 운영의 핵심 부분으로 만들면 코드 및 최종 사용자 환경의 품질이 크게 향상되었습니다. 운영에 완전히 참여함으로써 엔지니어링을 주요 이해 관계자로 만들어 더 나은 운영을 위해 설계된 시스템을 만들었습니다.