DevOps 원칙에 기반한 XNUMX가지 혁신 원형

'데브옵스를 어떻게 구현하느냐'라는 질문은 수년 간 제기됐지만 좋은 자료는 많지 않다. 때때로 당신은 어떻게든 시간을 팔아야 하는 그다지 똑똑하지 않은 컨설턴트의 광고에 희생양이 될 수 있습니다. 때때로 이것은 거대 기업의 선박이 우주의 광대한 땅을 어떻게 갈고 있는지에 대한 모호하고 매우 일반적인 단어입니다. 질문이 생깁니다. 이것이 우리에게 무슨 상관이 있습니까? 작가님, 당신의 아이디어를 목록으로 명확하게 정리할 수 있나요?

이 모든 것은 기업 문화 변화의 결과에 대한 실질적인 실천과 이해가 많이 축적되지 않았다는 사실에서 비롯됩니다. 문화의 변화는 장기적인 것이며 그 결과는 일주일이나 한 달 안에 나타나지 않습니다. 우리는 수년에 걸쳐 회사가 어떻게 구축되고 실패했는지 볼 수 있을 만큼 나이가 많은 사람이 필요합니다.

존 윌리스 - DevOps의 아버지 중 한 명. John은 수많은 회사에서 수십 년 동안 일한 경험을 가지고 있습니다. 최근 John은 그들 각각과 작업할 때 발생하는 특정 패턴을 발견하기 시작했습니다. John은 이러한 원형을 사용하여 기업을 DevOps 혁신의 진정한 길로 안내합니다. DevOops 2018 컨퍼런스 보고서 번역에서 이러한 원형에 대해 자세히 알아보세요.

스피커 소개:

IT 관리 분야에서 35년 이상 경력을 쌓았으며 Canonical에서 OpenCloud의 전신을 만드는 데 참여했으며 10개의 스타트업에 참여했으며 그 중 XNUMX개는 Dell과 Docker에 매각되었습니다. 현재 그는 SJ Technologies의 DevOps 및 디지털 업무 담당 부사장입니다.

다음은 존의 관점에서 본 이야기이다.

제 이름은 John Willis이고 저를 가장 쉽게 찾을 수 있는 곳은 트위터입니다. @botchagalupe. Gmail과 GitHub에 동일한 별칭이 있습니다. ㅏ 이 페이지에서 내 보고서와 프레젠테이션의 비디오 녹화물을 찾을 수 있습니다.

저는 다양한 대기업의 CIO들과 많은 미팅을 가졌습니다. 그들은 DevOps가 무엇인지 이해하지 못한다고 불평하는 경우가 많으며 DevOps를 설명하려는 모든 사람은 다른 것에 대해 이야기하고 있습니다. 또 다른 일반적인 불만은 DevOps가 작동하지 않는다는 것인데, 감독들이 설명대로 모든 일을 하고 있는 것 같습니다. 우리는 백년이 넘는 대기업에 대해 이야기하고 있습니다. 그들과 이야기를 나눈 후 나는 많은 문제에 가장 적합한 것은 첨단 기술이 아니라 상대적으로 낮은 기술 솔루션이라는 결론에 도달했습니다. 몇 주 동안 저는 여러 부서의 사람들과 이야기를 나눴습니다. 게시물의 첫 번째 사진에 보이는 것은 저의 마지막 프로젝트입니다. 작업 XNUMX일 후의 방의 모습입니다.

DevOps란 무엇입니까?

실제로 10명에게 물어보면 10개의 다른 대답이 나올 것이다. 하지만 흥미로운 점은 이 10가지 답이 모두 맞다는 것입니다. 여기에는 잘못된 대답이 없습니다. 저는 약 XNUMX년 동안 DevOps에 깊이 빠져 있었고 첫 번째 DevOpsDay에서 최초의 미국인이었습니다. 내가 DevOps에 관련된 모든 사람보다 똑똑하다고 말할 수는 없지만 DevOps에 많은 노력을 기울인 사람은 거의 없습니다. 저는 DevOps는 인적 자본과 기술이 합쳐질 때 발생한다고 믿습니다. 우리는 온갖 종류의 문화에 대해 많이 이야기하지만 인간의 차원에 대해서는 종종 잊어버립니다.

이제 우리는 많은 데이터, 2000년간의 학술 연구, 산업 규모의 이론 테스트를 보유하고 있습니다. 이러한 연구에서 알 수 있듯이 조직 문화에서 일부 행동 패턴을 결합하면 속도가 5000배 향상될 수 있습니다. 이 가속은 안정성의 동등한 향상과 일치합니다. 이는 DevOps가 모든 회사에 가져올 수 있는 이점을 정량적으로 측정한 것입니다. 몇 년 전 Fortune 5대 기업의 CEO에게 DevOps에 관해 이야기한 적이 있는데, 프레젠테이션을 준비할 때 수년간의 경험을 XNUMX분 안에 요약해야 해서 매우 긴장했습니다.

결국 나는 다음을 주었다 DevOps 정의: 인적자본을 고성과 조직자본으로 전환시키는 일련의 관행과 패턴이다. 한 가지 예는 지난 50~60년 동안 Toyota가 운영한 방식입니다.

(이하 해당 도표는 참고자료가 아닌 그림으로 제공됩니다. 내용은 신규 회사마다 다를 수 있습니다. 단, 해당 그림은 별도로 확인 및 확대하여 보실 수 있습니다. 이 링크에서.)

그러한 관행 중 가장 성공적인 것 중 하나는 값 스트림 매핑. 이에 관해 여러 좋은 책이 저술되었으며, 그중 가장 성공적인 책은 Karen Martin의 책입니다. 하지만 지난 XNUMX년 동안 저는 이 접근 방식조차 너무 첨단 기술이라는 결론에 도달했습니다. 확실히 장점이 많아서 많이 사용해봤습니다. 그러나 CEO가 자신의 회사가 왜 새로운 노선으로 전환할 수 없는지 묻는다면 가치 흐름 매핑에 대해 이야기하기에는 아직 이르습니다. 먼저 대답해야 할 훨씬 더 근본적인 질문이 많이 있습니다.

내 생각에 많은 동료들이 범하는 실수는 단순히 회사에 100가지 지침을 제공하고 150개월 후에 다시 돌아와 무슨 일이 일어났는지 살펴보는 것입니다. 가치 흐름 매핑과 같은 좋은 계획에도 사각지대가 있다고 가정해 보겠습니다. 다양한 회사의 이사들과 수백 차례의 인터뷰를 통해 저는 문제를 구성 요소별로 세분화할 수 있는 특정 패턴을 개발했으며 이제 이러한 각 구성 요소를 순서대로 논의하겠습니다. 나는 기술적인 해결책을 적용하기 전에 이 패턴을 사용하고 결과적으로 내 벽은 모두 다이어그램으로 덮여 있습니다. 최근에 나는 뮤추얼 펀드에서 일하고 있었는데 그러한 계획이 XNUMX-XNUMX개나 발생했습니다.

나쁜 문화는 아침 식사로 좋은 접근 방식을 먹습니다

주요 아이디어는 다음과 같습니다. 조직의 문화 자체가 나쁘다면 린(Lean), 애자일(Agile), SAFE 및 DevOps가 아무리 많아도 도움이 되지 않습니다. 이는 스쿠버 장비 없이 깊이 다이빙하거나 엑스레이 없이 작업하는 것과 같습니다. 즉, Drucker와 Deming을 바꿔 말하면 나쁜 조직 문화는 어떤 좋은 시스템도 질식시키지 않고 삼켜버릴 것입니다.

이 주요 문제를 해결하려면 다음 단계를 수행해야 합니다.

1. 모든 작업을 표시하도록 설정: 모든 작업을 볼 수 있도록 해야 합니다. 반드시 어떤 화면에 표시되어야 한다는 의미가 아니라, 관찰 가능해야 한다는 의미입니다.
2. 통합 작업 관리 시스템: 관리 시스템을 통합해야 합니다. "부족" 지식과 제도적 지식 문제에서 9명 중 10명은 병목 현상을 일으키는 사람입니다. 책에서 "피닉스 프로젝트" 문제는 브렌트(Brent)라는 한 사람에게 있었는데, 그로 인해 프로젝트가 예정보다 XNUMX년이나 늦어지게 되었습니다. 그리고 저는 어디에서나 이러한 "브렌트유"를 만나게 됩니다. 이러한 병목 현상을 해결하기 위해 목록의 다음 두 항목을 사용합니다.
3. 제약 방법론 이론: 제약 이론.
4. 협업 해킹: 협업 해킹.
5. 토요타 카타(카타 코칭): Toyota Kata에 대해서는 많이 이야기하지 않겠습니다. 관심이 있으시면 내 github에서 프레젠테이션이 있어요 이 주제의 거의 모든 것에 대해.
6. 시장지향적인 조직: 시장지향적인 조직.
7. Shift-왼쪽 감사자: 주기의 초기 단계에서 감사합니다.

저는 아주 간단하게 조직에서 일을 시작합니다. 회사에 가서 직원들과 이야기를 나누는 것입니다. 보시다시피 첨단 기술이 없습니다. 당신이 필요로하는 것은 쓸 내용뿐입니다. 나는 한 방에 여러 팀을 모아서 그들이 나에게 말하는 것을 나의 7가지 원형의 관점에서 분석합니다. 그리고는 스스로 마커를 주고 지금까지 말한 내용을 모두 칠판에 적어 달라고 합니다. 일반적으로 이러한 유형의 회의에는 모든 내용을 기록하는 사람이 한 명 있으며, 기껏해야 토론의 10%만 기록할 수 있습니다. 내 방법을 사용하면 이 수치를 약 40%까지 높일 수 있습니다.

(이 그림은 별도로 볼 수 있습니다 링크 참조)

나의 접근 방식은 William Schneider의 작업을 기반으로 합니다. 리엔지니어링 대안). 이 접근 방식은 모든 조직을 네 개의 사각형으로 나눌 수 있다는 생각에 기반을 두고 있습니다. 나에게 있어서 이 계획은 일반적으로 조직을 분석할 때 발생하는 수백 가지 다른 계획을 사용한 결과입니다. 통제 수준은 높지만 역량은 낮은 조직이 있다고 가정해 보겠습니다. 이것은 매우 바람직하지 않은 선택입니다. 모두가 최선을 다하고 있지만, 무엇을 해야 할지 아무도 모르는 경우입니다.

다소 더 나은 옵션은 통제력과 역량 모두 높은 수준을 갖춘 옵션입니다. 그러한 회사가 수익성이 있다면 아마도 DevOps가 필요하지 않을 것입니다. 높은 수준의 통제력, 낮은 역량, 협력성을 갖고 있지만 동시에 높은 수준의 문화(육성)를 갖춘 회사와 일하는 것이 가장 흥미롭습니다. 이는 회사에 그곳에서 일하고 싶어하는 사람들이 많고 이직률이 낮다는 것을 의미합니다.

(이 그림은 별도로 볼 수 있습니다 링크 참조)

엄격한 지침을 따르는 방법은 결국 진실을 달성하는 데 방해가 되는 것 같습니다. 특히 가치 흐름 매핑에는 정보를 구성하는 방법에 관한 많은 규칙이 있습니다. 지금 제가 이야기하고 있는 작업의 초기 단계에서는 누구도 이러한 규칙이 필요하지 않습니다. 마커를 손에 든 사람이 회사의 실제 상황을 칠판에 설명한다면 이것이 상황을 이해하는 가장 좋은 방법입니다. 그러한 정보는 이사에게 전달되지 않습니다. 이 순간, 그 사람의 말을 가로막고 화살을 잘못 그렸다고 말하는 것은 어리석은 일입니다. 이 단계에서는 간단한 규칙을 사용하는 것이 더 좋습니다. 예를 들어 여러 색상의 마커를 사용하여 간단히 다단계 추상화를 만들 수 있습니다.

반복합니다. 첨단 기술은 없습니다. 검은색 마커는 모든 것이 어떻게 작동하는지에 대한 객관적인 현실을 나타냅니다. 빨간색 마커를 사용하여 사람들은 현재 상황에서 마음에 들지 않는 점을 표시합니다. 내가 아니라 그들이 이 글을 쓰는 것이 중요합니다. 회의 후 CIO에게 갈 때 수정해야 할 10가지 목록을 제시하지 않습니다. 나는 회사 사람들이 말하는 것과 기존의 입증된 패턴 사이의 연관성을 찾으려고 노력합니다. 마지막으로 파란색 마커는 문제에 대한 가능한 해결책을 제안합니다.

(이 그림은 별도로 볼 수 있습니다 링크 참조)

이제 이 접근 방식의 예가 위에 설명되어 있습니다. 올해 초에 저는 한 은행에서 일했습니다. 그곳의 보안 담당자들은 설계 및 요구 사항 검토에 참여해서는 안 된다고 확신했습니다.

(이 그림은 별도로 볼 수 있습니다 링크 참조)

그런 다음 다른 부서의 사람들과 이야기를 나눴는데 약 8년 전에 소프트웨어 개발자들이 작업 속도를 늦춘다는 이유로 보안 직원을 해고했다는 사실이 밝혀졌습니다. 그리고 그것은 당연한 것으로 받아들여진 금지령으로 바뀌었습니다. 실제로는 금지가 없었습니다.

우리 회의는 극도로 혼란스러운 방식으로 진행되었습니다. 약 XNUMX시간 동안 다섯 개의 서로 다른 팀이 코드와 어셈블리 사이에 무슨 일이 일어나고 있는지 설명할 수 없었습니다. 그리고 이것이 가장 간단한 것 같습니다. 대부분의 DevOps 컨설턴트는 모든 사람이 이미 이 사실을 알고 있다고 가정합니다.

그러다가 XNUMX시간 동안 침묵을 지켰던 IT 거버넌스 담당자가 화제가 되자 갑자기 살아나더니 아주 오랜 시간 동안 우리를 사로잡았습니다. 마지막에 나는 그에게 회의에 대해 어떻게 생각하는지 물었고 나는 그의 대답을 결코 잊지 않을 것입니다. 그는 “예전에는 우리 은행에 소프트웨어를 전달하는 방법이 두 가지밖에 없다고 생각했는데, 지금은 그 중 다섯 가지가 있다는 것을 알고 있고 세 가지도 몰랐다”고 말했다.

(이 그림은 별도로 볼 수 있습니다 링크 참조)

이 은행의 마지막 회의는 투자 소프트웨어 팀과의 만남이었습니다. 그녀와 함께 종이에 마커로 다이어그램을 쓰는 것이 보드보다 낫고 스마트 보드보다 더 낫다는 것이 밝혀졌습니다.

지금 보시는 사진은 미팅 XNUMX일차에 있었던 호텔 회의실의 모습입니다. 그리고 우리는 이러한 체계를 사용하여 패턴, 즉 원형을 검색했습니다.

그래서 직원들에게 질문을 하면 직원들은 세 가지 색상(검은색, 빨간색, 파란색)으로 된 마커로 답을 적습니다. 나는 원형에 대한 그들의 답변을 분석합니다. 이제 모든 원형을 순서대로 논의해 보겠습니다.

1. 모든 작업 표시: 작업 표시

내가 함께 일하는 대부분의 회사에는 알려지지 않은 작업의 비율이 매우 높습니다. 예를 들어, 한 직원이 다른 직원에게 와서 단순히 무언가를 요청하는 경우입니다. 대규모 조직에서는 계획되지 않은 작업이 60% 있을 수 있습니다. 그리고 작업의 최대 40%는 어떤 방식으로든 문서화되지 않습니다. 보잉이었다면 내 인생에서 다시는 그 비행기에 탑승하지 않을 것입니다. 작업의 절반만 문서화되면 이 작업이 올바르게 수행되고 있는지 여부를 알 수 없습니다. 다른 모든 방법은 쓸모가 없는 것으로 판명됩니다. 알려진 50%가 작업의 가장 일관되고 명확한 부분일 수 있으며 자동화는 좋은 결과를 얻지 못하고 최악의 결과를 가져올 수 있기 때문에 아무것도 자동화하려고 시도할 필요가 없습니다. 사물은 보이지 않는 절반에 있습니다. 문서가 없으면 모든 종류의 해킹과 숨겨진 작업을 찾는 것이 불가능하며 병목 현상, 즉 제가 이미 이야기한 바로 "브렌트"를 찾는 것이 불가능합니다. Dominica DeGrandis의 훌륭한 책이 있습니다. "작업을 눈에 띄게 만들기". 그녀는 공개한다 다섯 가지 "시간 누출" (시간 도둑):

• 진행 중인 작업(WIP)이 너무 많습니다.
• 알 수 없는 종속성
• 계획되지 않은 작업
• 우선순위 충돌
• 소외된 업무

이것은 매우 가치 있는 분석이고 책도 훌륭하지만, 데이터의 50%만 표시된다면 이 모든 조언은 쓸모가 없습니다. 90% 이상의 정확도가 달성되면 Dominica가 제안한 방법을 사용할 수 있습니다. 나는 상사가 부하 직원에게 15분짜리 작업을 주지만 부하 직원에게는 XNUMX일이 걸리는 상황에 대해 이야기하고 있습니다. 하지만 상사는 이 부하 직원이 XNUMX~XNUMX명의 다른 사람에게 의존하고 있다는 사실을 실제로 알지 못합니다.

피닉스 프로젝트(Phoenix Project)는 90년이나 늦어진 프로젝트에 대한 놀라운 이야기입니다. 이로 인해 인물 중 한 명이 해고를 당하게 되고, 그는 일종의 소크라테스로 제시되는 또 다른 인물을 만나게 된다. 그는 정확히 무엇이 잘못되었는지 파악하는 데 도움을 줍니다. 회사에는 Brent라는 이름의 시스템 관리자가 한 명 있으며 모든 작업이 어떻게 든 그를 통해 진행되는 것으로 나타났습니다. 회의 중 하나에서 부하 직원 중 한 명이 질문을 받습니다. 각 9분 작업에 일주일이 걸리는 이유는 무엇입니까? 그 대답은 대기열 이론과 리틀의 법칙을 매우 단순화한 프레젠테이션이며, 이 프레젠테이션에서는 63% 점유율에서 각 작업 시간이 7시간이 걸리는 것으로 나타났습니다. 각 작업은 다른 9명에게 전송되어야 하며, 그러면 그 시간은 XNUMX시간, XNUMX×XNUMX가 됩니다. 제가 말하고자 하는 것은 리틀의 법칙이나 복잡한 대기열 이론을 사용하려면 최소한 데이터가 필요하다는 것입니다.

따라서 가시성에 대해 이야기할 때 모든 것이 화면에 표시된다는 의미가 아니라 최소한 데이터가 있다는 의미입니다. 그렇게 할 때, 필요하지 않은데 어떻게든 브렌트에게 전송되는 계획되지 않은 작업의 양이 매우 많다는 사실이 종종 밝혀졌습니다. 그리고 브렌트는 훌륭한 사람입니다. 그는 결코 거절하지 않을 것입니다. 그러나 그는 자신의 일을 어떻게 하는지 아무에게도 말하지 않습니다.

작업이 보이면 데이터를 깔끔하게 분류할 수 있고(사진에서 도미니크가 하고 있는 일이 바로 그것이다), XNUMX번의 시간 누수에 대한 추상화를 적용할 수 있고, 자동화를 적용할 수 있다.

2. 업무 관리 시스템 통합: 업무 관리

내가 말하는 원형은 일종의 피라미드이다. 첫 번째 작업이 올바르게 수행되면 두 번째 작업은 이미 일종의 추가 기능입니다. 이들 중 다수는 스타트업에는 적합하지 않으며 Fortune 5000대 기업과 같은 대규모 회사에서는 염두에 두어야 합니다. 제가 근무했던 마지막 회사에는 티켓팅 시스템이 10개 있었습니다. 한 팀은 Remedy를 사용했고, 다른 팀은 자체 시스템을 작성했으며, 세 번째 팀은 Jira를 사용했고, 일부는 이메일을 사용했습니다. 회사에 30개의 파이프라인이 있는 경우에도 동일한 문제가 발생하지만 이러한 경우를 모두 논의할 시간은 없습니다.

나는 티켓이 어떻게 생성되는지, 다음에 어떤 일이 발생하는지, 어떻게 티켓을 우회하는지 사람들과 정확히 논의합니다. 가장 흥미로운 점은 우리 모임에 참석한 사람들이 아주 진지하게 말한다는 것입니다. 실제로 "큰 영향"을 주어야 하는 티켓에 "미미/영향 없음"을 부여하는 사람이 몇 명인지 물었습니다. 거의 모든 사람이 이렇게 한다는 것이 밝혀졌습니다. 나는 비난에 참여하지 않으며 가능한 모든 방법으로 사람의 신원을 확인하지 않으려 고 노력합니다. 진심으로 고백하면 그 사람을 내어주지 않아요. 그러나 거의 모든 사람이 시스템을 우회한다는 것은 모든 보안이 본질적으로 윈도우 드레싱이라는 것을 의미합니다. 따라서 이 시스템의 데이터에서는 결론을 도출할 수 없습니다.

티켓 문제를 해결하려면 하나의 메인 시스템을 선택해야 합니다. Jira를 사용하는 경우 Jira를 유지하세요. 대안이 있다면 그것이 유일한 대안이 되도록 하십시오. 결론은 티켓을 개발 프로세스의 또 다른 단계로 보아야 한다는 것입니다. 모든 작업에는 개발 워크플로를 통해 진행되어야 하는 티켓이 있어야 합니다. 티켓은 팀으로 전송되며, 팀은 이를 스토리보드에 게시한 다음 이에 대한 책임을 집니다.

이는 인프라와 운영을 포함한 모든 부서에 적용됩니다. 이 경우 상황에 대한 최소한의 그럴듯한 아이디어를 형성하는 것이 가능합니다. 이 프로세스가 확립되면 각 애플리케이션의 책임자를 식별하는 것이 갑자기 쉬워집니다. 이제 우리는 새로운 서비스의 50%가 아닌 98%를 받기 때문입니다. 이 핵심 프로세스가 작동하면 시스템 전체의 정확성이 향상됩니다.

서비스 파이프라인

이는 다시 대기업에만 적용됩니다. 새로운 분야의 신생 회사라면 소매를 걷어붙이고 Travis CI 또는 CircleCI와 협력하세요. Fortune 5000대 기업의 경우 제가 근무했던 은행에서 있었던 일이 대표적입니다. Google이 그들에게 와서 오래된 IBM 시스템의 다이어그램을 보여주었습니다. Google 직원들이 혼란스러워서 물었습니다. 이에 대한 소스 코드는 어디에 있습니까? 하지만 소스 코드도 없고 GUI도 없습니다. 이것이 대규모 조직이 처리해야 하는 현실입니다. 오래된 메인프레임에 있는 40년 된 은행 기록입니다. 내 고객 중 한 명은 KeyBank 애플리케이션을 위해 Circuit Breaker 패턴과 Chaos Monkey가 포함된 Kubernetes 컨테이너를 사용합니다. 그러나 이러한 컨테이너는 궁극적으로 COBOL 애플리케이션에 연결됩니다.

Google 직원들은 내 고객의 모든 문제를 해결할 것이라고 완전히 확신한 다음 질문을 하기 시작했습니다. IBM 데이터파이프가 무엇인가요? 그들은 이것이 커넥터라고 들었습니다. 그것은 무엇과 연결됩니까? Sperry 시스템으로. 그게 뭐죠? 등등. 언뜻 보면 어떤 종류의 DevOps가 있을 수 있을까요? 그러나 실제로는 가능합니다. 워크플로를 배송 팀에 넘길 수 있는 배송 시스템이 있습니다.

3. 제약이론: 제약이론

세 번째 원형인 제도적/"부족적" 지식으로 넘어가겠습니다. 일반적으로 모든 조직에는 모든 것을 알고 모든 것을 관리하는 여러 사람이 있습니다. 이들은 조직에 가장 오래 있었고 모든 해결 방법을 알고 있는 사람들입니다.

이것이 다이어그램에 나타나면 나는 마커로 그러한 사람들에게 특별히 동그라미를칩니다. 예를 들어 특정 Lou가 모든 회의에 참석하는 것으로 밝혀졌습니다. 그리고 그것은 나에게 분명합니다. 이것은 지역 브렌트입니다. CIO가 티셔츠와 운동화를 입은 나와 정장을 입은 IBM 직원 중 하나를 선택할 때, 내가 선택되는 이유는 다른 사람이 말하지 않을 것과 디렉터가 듣고 싶어하지 않을 수도 있는 것들을 감독에게 말할 수 있기 때문입니다. . 나는 회사의 병목 현상이 Fred라는 사람과 Lou라는 사람이라고 말합니다. 이 병목 현상을 풀어야 하며, 어떤 식으로든 그들로부터 지식을 얻어야 합니다.

이런 종류의 문제를 해결하려면 예를 들어 Slack을 사용하는 것이 좋습니다. 똑똑한 감독이 물을 것입니다 - 왜? 일반적으로 이러한 경우 DevOps 컨설턴트는 다음과 같이 대답합니다. 모두가 그렇게 하고 있기 때문입니다. 감독이 정말 똑똑하다면 그는 이렇게 말할 것입니다. 그리고 이것이 대화가 끝나는 곳입니다. 이에 대한 나의 대답은 다음과 같습니다. 회사에 Fred, Lou, Susie 및 Jane이라는 네 가지 병목 현상이 있기 때문입니다. 지식을 제도화하려면 먼저 Slack을 도입해야 합니다. 귀하의 모든 위키는 그 존재에 대해 아무도 모르기 때문에 완전히 말도 안되는 것입니다. 엔지니어링 팀이 프런트엔드 및 백엔드 개발에 참여하고 모든 사람이 프런트엔드 개발팀이나 인프라 팀에 질문을 문의할 수 있다는 점을 알아야 합니다. 그때가 바로 Lou나 Fred가 위키에 참여할 시간을 갖게 될 것입니다. 그런 다음 Slack에서 누군가가 왜 5단계가 작동하지 않는지 묻는 경우 Lou나 Fred가 Wiki의 지침을 수정합니다. 이 프로세스를 확립하면 많은 일이 저절로 이루어집니다.

이것이 나의 주요 요점입니다. 첨단 기술을 추천하려면 먼저 그에 대한 기반을 정리해야 하며 이는 방금 설명한 저급 기술 솔루션을 사용하여 수행할 수 있습니다. 첨단 기술로 시작하고 그 기술이 필요한 이유를 설명하지 않으면 일반적으로 잘 끝나지 않습니다. 우리 고객 중 한 명은 매우 저렴하고 간단한 솔루션인 Azure ML을 사용합니다. 질문의 약 30%는 자가 학습 기계 자체에서 답변되었습니다. 그리고 이 글은 데이터 과학, 통계, 수학에 관련되지 않은 운영자가 작성한 것입니다. 이것은 중요합니다. 그러한 솔루션의 비용은 최소화됩니다.

4. 협업 해킹: 협업 해킹

네 번째 원형은 고립에 맞서 싸울 필요성입니다. 대부분의 사람들은 이미 이것을 알고 있습니다. 고립은 적대감을 낳습니다. 각 부서가 자신의 층에 있고 엘리베이터를 제외하고 사람들이 어떤 식 으로든 서로 교차하지 않으면 그들 사이에 적대감이 매우 쉽게 발생합니다. 그러나 반대로 사람들이 같은 방에 있으면 그녀는 즉시 떠납니다. 예를 들어 누군가가 그러한 인터페이스가 결코 작동하지 않는다는 일반적인 비난을 던지면 그러한 비난을 해체하는 것이 더 쉬운 것은 없습니다. 인터페이스를 작성한 프로그래머는 구체적인 질문을 하기만 하면 되며, 예를 들어 사용자가 단순히 도구를 잘못 사용하고 있었다는 사실이 곧 분명해질 것입니다.

고립을 극복하는 방법에는 여러 가지가 있습니다. 한번은 호주의 한 은행에 상담해 달라는 요청을 받았지만 두 자녀와 아내가 있다는 이유로 거절했습니다. 그들을 돕기 위해 내가 할 수 있는 일은 그래픽 스토리텔링을 추천하는 것뿐이었습니다. 이는 효과가 입증된 것입니다. 또 다른 흥미로운 방법은 린 커피 미팅입니다. 대규모 조직에서 이는 지식을 전파하는 데 탁월한 옵션입니다. 또한 내부 데브옵스데이, 해커톤 등을 진행할 수 있습니다.

5. 카타 코칭

처음에 경고했듯이 오늘은 이에 대해 이야기하지 않겠습니다. 관심있으신 분들은 한번 살펴보시면 좋을 것 같아요 내 프레젠테이션 중 일부.

이 주제에 관해 Mike Rother의 좋은 강연도 있습니다:

6. 시장지향적: 시장지향적인 조직

여기에는 다른 문제가 있습니다. 예를 들어 "I" 사람, "T" 사람, "E" 사람이 있습니다. '나'라는 사람은 오직 한 가지 일만 하는 사람입니다. 일반적으로 이들은 분리된 부서가 있는 조직에 존재합니다. "T"는 사람이 한 가지 일을 잘하지만 다른 일도 잘하는 경우입니다. "E" 또는 심지어 "comb"은 사람이 많은 기술을 가지고 있을 때 사용됩니다.

콘웨이의 법칙은 여기서 작동합니다(콘웨이의 법칙), 가장 단순화된 형식으로 다음과 같이 설명할 수 있습니다. 세 팀이 컴파일러를 작업하는 경우 결과는 세 부분으로 구성된 컴파일러가 됩니다. 따라서 조직 내 격리 수준이 높으면 이 조직의 Kubernetes, 회로 차단기, API 확장성 및 기타 멋진 것조차도 조직 자체와 동일한 방식으로 배열됩니다. 엄격하게 Conway에 따르면 모든 젊은 괴짜들을 괴롭히는 것입니다.

이 문제에 대한 해결책은 여러 번 설명되었습니다. 예를 들어 페르난도 페르난데스(Fernando Fernandez)가 설명한 조직 원형이 있습니다. 제가 방금 이야기한 문제가 있는 아키텍처는 기능 지향 아키텍처입니다. 두 번째 유형은 최악의 매트릭스 아키텍처로, 다른 두 가지 유형 중 엉망입니다. 세 번째는 대부분의 스타트업에서 볼 수 있는 형태인데, 대기업도 이런 유형을 맞추려고 노력하고 있다. 시장지향적인 조직입니다. 여기서 우리는 고객 요청에 가장 빠른 응답을 달성하기 위해 최적화합니다. 이를 수평적 조직이라고도 합니다.

많은 사람들이 이 구조를 다양한 방식으로 설명합니다. 저는 다음과 같은 표현을 좋아합니다. 팀 구축/운영, Amazon에서는 이렇게 부릅니다. 두 개의 피자 팀. 이런 구조에서는 모든 'I'형 사람들이 하나의 서비스를 중심으로 그룹화되어 점차 'T'형에 가까워지고, 올바른 관리가 이루어지면 'E'형도 될 수 있습니다. 여기서 첫 번째 반론은 그러한 구조에는 불필요한 요소가 있다는 것입니다. 특별한 테스터 부서를 가질 수 있다면 각 부서에 테스터가 필요한 이유는 무엇입니까? 제가 대답하자면, 이 경우 추가 비용은 전체 조직이 미래에 "E" 유형이 되기 위한 비용입니다. 이 구조에서 테스터는 네트워크, 아키텍처, 디자인 등에 대해 점차적으로 학습합니다. 결과적으로 조직의 모든 참가자는 조직에서 일어나는 모든 일을 완전히 알고 있습니다. 이 계획이 업계에서 어떻게 작동하는지 알고 싶다면 다음을 읽어보세요. 마이크 로더, 토요타 카타.

7. Shift-left 감사자: 주기 초기에 감사합니다. 전시된 안전 규칙 준수

말하자면 당신의 행동이 냄새 테스트를 통과하지 못하는 경우입니다. 당신을 위해 일하는 사람들은 바보가 아닙니다. 위의 예에서처럼 모든 곳에 경미하거나 영향을 주지 않고 XNUMX년 동안 지속되었으며 아무도 아무것도 눈치채지 못했다면 시스템이 작동하지 않는다는 것을 모두가 잘 알고 있는 것입니다. 또는 또 다른 예로는 매주 수요일마다 보고서를 제출해야 하는 변경 자문 위원회가 있습니다. 이론적으로 시스템 전체가 어떻게 작동하는지 알아야 하는 사람들이 거기에서 일하고 있습니다(그나저나 급여가 그리 좋지는 않습니다). 그리고 지난 XNUMX년 동안 여러분은 아마도 우리 시스템이 엄청나게 복잡하다는 것을 알아차리셨을 것입니다. 그리고 XNUMX~XNUMX명의 사람들은 자신이 하지도 않았고 아무것도 모르는 변화에 대해 결정을 내려야 합니다.

물론 이 접근 방식은 작동하지 않습니다. 이런 사람들은 시스템을 보호하지 않기 때문에 그런 것들을 없애야 합니다. 결정은 팀이 직접 해야 한다. 왜냐하면 팀이 책임을 져야 하기 때문이다. 그렇지 않으면 평생 코드를 작성해 본 적이 없는 관리자가 프로그래머에게 코드를 작성하는 데 시간이 얼마나 걸릴지 알려주면 역설적인 상황이 발생합니다. 제가 함께 일했던 한 회사에는 아키텍처 보드, 제품 보드 등 모든 변경 사항을 검토하는 7개의 보드가 있었습니다. 의무 대기 기간도 있었지만 한 직원은 XNUMX년 동안 근무하면서 이 의무 기간 동안 이 사람이 변경한 사항을 거부한 사람은 아무도 없었다고 말했습니다.

감사자는 우리와 함께하도록 초대받아야 하며, 그들을 제거해서는 안 됩니다. 모든 테스트를 통과하면 영원히 불변으로 유지되는 불변 바이너리 컨테이너를 작성한다고 알려주세요. 코드형 파이프라인이 있다고 말하고 그것이 무엇을 의미하는지 설명하세요. 다음 구성표를 보여주십시오. 모든 취약성 테스트를 통과한 컨테이너의 변경 불가능한 읽기 전용 바이너리입니다. 그러면 아무도 그것을 건드리지 않을 뿐만 아니라 파이프라인을 생성하는 시스템도 건드리지 않습니다. 왜냐하면 파이프라인도 동적으로 생성되기 때문입니다. Vault를 사용하여 블록체인과 같은 것을 만드는 고객인 Capital One이 있습니다. 감사자는 Chef의 "레시피"를 보여줄 필요가 없으며 블록체인을 보여주는 것만으로도 충분하며 이를 통해 프로덕션에서 Jira 티켓에 무슨 일이 일어났는지, 누가 책임을 지고 있는지 명확하게 알 수 있습니다.

에 따르면 보고서2018년 Sonatype이 만든 는 2017년에 87억 건의 OSS 다운로드 요청이 있었습니다.

취약점으로 인해 발생하는 손실은 엄청납니다. 게다가 지금 위에 보이는 수치에는 기회비용이 포함되어 있지 않습니다. 간단히 말해서 DevSecOps란 무엇입니까? 나는 이 이름이 얼마나 성공적인지에 대해 이야기하는 데 관심이 없다는 것을 즉시 말씀드리겠습니다. 요점은 DevOps가 매우 성공적이었으므로 해당 파이프라인에 보안을 추가해야 한다는 것입니다.

이 시퀀스의 예:


나는 모든 제품을 좋아하지만 특정 제품에 대한 권장 사항은 아닙니다. 나는 처음에 업계의 조직적 패러다임을 기반으로 한 DevOps를 통해 제품에 대한 모든 작업 단계를 자동화할 수 있음을 보여주기 위해 이를 예로 들었습니다.

보안에 대해서도 동일한 접근 방식을 취하지 못할 이유가 없습니다.

합계

결론적으로 DevSecOps에 대한 몇 가지 팁을 제공하겠습니다. 시스템을 만드는 과정에 감사자를 포함시키고 교육하는 데 시간을 투자해야 합니다. 감사관과 협력해야 합니다. 다음으로, 오탐에 맞서 절대적으로 무자비한 싸움을 벌여야 합니다. 가장 비싼 취약점 검색 도구를 사용하더라도 신호 대 잡음 비율이 무엇인지 모르면 개발자들 사이에 극도로 나쁜 습관이 생길 수 있습니다. 개발자는 이벤트로 인해 압도당하고 이를 삭제하게 됩니다. Equifax 이야기를 들어보셨다면 가장 높은 경고 수준이 무시되었던 그곳에서 일어난 일이 거의 바로 그것입니다. 또한 취약점이 비즈니스에 어떤 영향을 미치는지 명확하게 설명할 수 있어야 합니다. 예를 들어, 이것이 Equifax 이야기에서와 동일한 취약점이라고 말할 수 있습니다. 보안 취약성은 다른 소프트웨어 문제와 동일하게 처리되어야 합니다. 즉, 전체 DevOps 프로세스에 포함되어야 합니다. Jira, Kanban 등을 통해 협력해야 합니다. 개발자는 다른 사람이 이 작업을 수행할 것이라고 생각해서는 안 됩니다. 반대로 모든 사람이 이를 수행해야 합니다. 마지막으로, 사람들을 훈련시키는 데 에너지를 소비해야 합니다.

유용한 링크

다음은 귀하에게 유용할 수 있는 DevOops 컨퍼런스의 몇 가지 강연입니다.

• Sergey Berdnikov, Artyom Kalichkin - 성공 사례 또는 "Dev+DevOps+Ops"(비디오, 보고서의 사본)
• Baruch Sadogursky, Leonid Igolnik - 규모에 따른 DevOps: XNUMX막으로 구성된 그리스 비극(비디오, 보고서의 사본)
• 알렉산더 티토프, 키릴 톨카체프 - DevOps, 엔지니어 및 커뮤니티
• 티모시 리스터 - 인물, 공동체, 문화: 번영의 중요한 요소

들여다보다 программу DevOops 2020 모스크바 — 거기에는 흥미로운 것들이 많이 있습니다.

출처 : habr.com