팀의 개발자들이“당신은 그것을 구축하고 운영합니다”라고 포용하도록 어떻게 설득 할 수 있습니까?

팀의 개발자가 "빌드 구축, 실행"을 수용하도록 어떻게 설득 할 수 있습니까? 베르너 보겔 스 (Werner Vogels) 는 다음과 같이 인용했습니다 .

개발자에게 운영 책임을 부여하면 고객 및 기술 관점에서 서비스 품질이 크게 향상되었습니다. 기존 모델은 소프트웨어를 개발 및 운영을 분리하는 벽으로 가져간 다음 버리고 잊어 버리는 것입니다. 아마존에는 없습니다. 당신은 그것을 구축하고 실행합니다. 이를 통해 개발자는 일상적인 소프트웨어 운영에 연락 할 수 있습니다. 또한 고객과 매일 연락하게됩니다. 이 고객 피드백 루프는 서비스 품질을 향상시키는 데 필수적입니다.

특히 다음과 같은 개발자 세트를 생각하고 있습니다.

• 작전 관련 작업에 대한 언급이 거의 없거나 전혀없는 개발자 역할로 고용되었습니다.
• 전통적으로 작전 팀에게 "벽에 코드를 던졌습니다".
• 전통적으로 9-5 개의 근무 일정이 있으며 특히 " 업무 시간"이외의 재해 복구, 사후 쓰기 등에 참여하는 "pager duty"아이디어에 적대적 입니다. (참고 :이 문제에 대해서는 매우 드물게 중단되는 경우 만 있으므로이 팀의 작업 부하에 시간 외 고객 지원을 추가 할 것을 제안하지 않습니다.)
• 현재 응용 프로그램에 대한 모니터링 또는 경고 작성 / 지원에 대한 책임이 없습니다.

이러한 서비스를 운영팀에 전달하는 것이 좋지 않은 프로필을 사용하여 새로운 클라우드 마이크로 서비스를 신속하게 개발하는 팀이 있다고 가정 해 봅시다. 효과적으로 관리하고 모니터링하는 데 필요한 서비스 업무를 담당하는 각 팀 구성원에게 위임 할 수 있기 때문에 "구축하고 실행하면"이 팀에 더 효과적입니다. 따라서이 팀은 인프라 설계, 서비스 모니터링 / 경고 도구, 중단 이벤트에 매우 드물게 참여하기 시작했습니다.

저는 실제 사례로 뒷받침되는 방법론에 특히 관심이 있습니다. 이것이 다른 작업장에서 어떻게 성공적으로 구현되었으며, 이것을 구현하는 동안 따라야 할 정식 단계가 있습니까? 답변을 뒷받침 할 수있는 글쓰기 링크는 매우 유용합니다.

가장 쉬운 방법은 성능 목표를 변경하여 신뢰성과 코드 전달을 기반으로하는 것입니다. 회사가 둘 다 없이는 성공할 수 없기 때문에 그것을 판매하십시오. 왜 개발자는 하나만 평가해야합니까? 그런 다음 성과 목표를 달성하는 가장 좋은 방법은 운영에 참여하는 것입니다.

궁극적으로 이것이 회사가 성공하고 성공할 수있는 가장 좋은 방법임을 확신시켜야합니다. 힘들고 처음부터 온보드를 기대할 수는 없습니다. 그들은 그 가치에 대해서도 팔아야합니다.

비즈니스 문화에 영향을 줄 때 가장 좋은 방법은 잘 알려진 "개구리 끓이기"방법 일 것입니다. 나 자신 (개발자)이이 모든 새로운 책임을 한꺼번에 받아 들일 것이라는 것을 알고 있기 때문에 개발자에게 이러한 작업을 천천히 소개해야합니다.

첫째, 정상적인 업무 시간 동안 만 수행 할 하나 또는 두 개의 새 작업을 시작하여 시작하십시오. 그들은 (이 시점까지) 코드 전용 개발자를위한 학습 과정이 될 수있는 devops를 수행하는 방법을 배워야하며 약간의 감독이 필요할 수 있습니다. 그들은 당신이 9-5에 익숙하다고 언급하기 때문에 일과 삶의 균형을 바꾸려는 생각에 적대적 일 것입니다. 이 시점에서 나중에 사용하기 위해 새 프로세스에 데이터를 기록하십시오 (이 코드를 작성하도록하십시오. 데이터는 항상 유용합니다).

나중에 소개 할 새로운 개발 작업이 부족할 때 (첫 번째, 두 번째 및 네 번째 글 머리 기호가 거의 완료 됨) 표준 작업 시간 이외의 시간에 수행 할 후보로 첫 번째 작업을 수행하십시오. . 당신은 이것에 약간의 반발을 볼 수 있으며, 당신이 이것을 얼마나 강하게 밀고 있는지 그리고 5시에 일하는 문화가 얼마나 심하게 뿌리 내리고 있는지에 따라 약간의 마멸을 볼 수도 있습니다. 이를 막기 위해 귀하의 데이터가 표준 시간 이후의 작업은 드물고 극한 상황에서만 발생하며 비즈니스와 고객 모두에게 큰 이익이 될 것이라는 아이디어를 지원하기를 바랍니다. 데이터가이를 지원하지 않으면이 선택의 결과를 처리 할 준비가되어있는 것이 좋습니다.

데이터가 있더라도 개발자가 모니터링 / 경고 코드를 작성하고 (따라서 개발 운영팀이되지만 여전히 개발팀이되어) 대체 운영팀을 일선 지원으로 유지하는 것이 더 쉬울 수 있습니다 ( 다른 사람들이 제안한대로). 내가 말했듯이, 백래시를 피하기 위해 작은 변화가 중요합니다. 표준 시간 이상으로 개발자를위한 작업을 통합하는 것은 어려울 것입니다. 개발자 시장이 현재 강력하기 때문에, 특히 이미 숙련 된 기술을 보유하고 있기 때문에 그들이 원한다면 다른 곳에서 구직 할 수 있다는 것을 알 수 있기 때문입니다. 경고 주의자!

구체적으로 DevOps 외부를 살펴보면 대규모 (ish) 엔터프라이즈 환경에 대해 이야기하는 경우 SAFe 방법론은 이러한 종류의 동작을 장려하는 상당히 좋은 방법입니다.

기본적으로 몇 가지 주요 단계로 요약됩니다.

• 프로젝트는 릴리즈 트레인으로 시작됩니다. 의도는 (그리고 자금을 지원하는 사람의 기대) 장기적으로 지속될 것이라는 것입니다. 나는 몇 년 동안 이야기하고 있는데,이 중 어느 것도 "3 개월 동안 한 팀을 일으킨 다음 그 일을하지 않는다"는 사업은 없습니다.

• 프로젝트 과정에서 릴리즈 트레인은 새로 구현 된 비즈니스 기회와 지속적인 유지 보수 스타일 작업 세금을 기반으로 한 새로운 프로젝트 요구 사항 중 더 많은 사람들로 인해 더 많은 사람들을 필연적으로 모을 것입니다.

• 나는 거의 항상 열차가 첫 번째 증분을 100 % 프로젝트 / 변경 팀으로 운영하는 것을보고, 두 번째 증분은 운행 시간에 일정 비율을 할당합니다. 3 차 증분 관리는 문제가 발생하고 팀을 추가하여 Run 오버 플로우를 시도하고 처리하여 이제 숙련 된 개발자와 엔지니어가 새로운 요구 사항을 계속 처리 할 수있는 시간을 제공 할 수 있음을 인식합니다.

• 프로젝트 팀이 유지 보수 작업에 많은 어려움을 겪지 않고 프로젝트 결과를 계속 제공 할 수 있고 올바른 기차에 합류하면 새로운 팀이 즉시 100 % 지원 팀이 될 것으로 예상되지 않고 대신 처리해야 할 변경 작업의 상당 부분을 처리하면 기본적으로 빌드하는 제품을 소유하는 배송 팀이 생깁니다. 이제는 실행 팀이라는 것을 한 번에 확인할 필요가 없습니다. 대신 일상 활동에 천천히 통합됩니다.

이 모델이 분명히 약점을 가지고있는 곳은 비즈니스의 가격입니다. 일반적으로 실행 리소스보다 변경 리소스에 대해 더 많은 비용을 지불 할 것으로 예상됩니다. 일반적으로 주요 공급 업체와의 실행 계약은 고정 가격이며 지속적인 개선으로 인해 돈을 버는 것이므로 비용을 절감 할 수 있습니다.

그럼에도 불구하고, 변경 팀이 단순히 지속적인 개선을 제공하기 위해 릴리스 트레인의 일부로 떠올랐다는 것은 그리 어려운 일이 아닙니다. 새로운 프로젝트 제공에 집중할 수있는 능력을 향상시키고 "평상시와 같은 비즈니스"작업에 덜 관심을 가지게 할 수있는 것들이 있거나 구축 할 수있는 일이 있다면,이를 위해 돈을 보유한 사람에 의해 인식 된 이익에 기초하여 백 로그되고 우선 순위가 정해져 야합니다 기차를 풀어 라.

IMHO You build it, you run it는 말 그대로 받아 들여서는 안됩니다. 시작하려면-그것은 거의 처벌처럼 들립니다.)

어떤 한 사람 또는 소규모 개발 팀은 수 합리적 도구 또는 소프트웨어 개발 프로세스에 사용되는 도구 세트를 지원하지 (생산 즉!) 오랜 기간 동안. 거기에 있었어 :)

툴 (세트) 고객 기반이 증가함에 따라 지원 업무가 확대되는 경향이 있습니다. 이러한 직무를 전적으로 가정한다면 개발 팀은 개발을위한 시간이 거의 없거나 거의없이 대부분 지원을받을 수 있습니다. 사실상 막 다른 골목-그러한 환경에서 몇 명의 개발자가 고집하고 싶습니까?

프로페셔널 1 차 지원 팀을 보유하는 것은 개발자 팀 멤버에 대한 지원 업무에 대한 장기적인 노출의 좌절, 스트레스 및 기타 영향을 방지하는 데 중요합니다.

물론, 1 차 지원 팀은 개발자 팀 (단독자가 아닌 팀)에게 직접 다루어 질 수없는 문제에 대해 대체 할 것입니다. 예, 처음에는 어려울 수 있지만 상황이 나아질 것입니다. 공동 작업이어야합니다. DevOps의 일부입니다.

이것은 궁극적으로 회사의 규모와 구조에 달려 있습니다. 회사가 실제로 할 수있는 단계는 세 가지가 있습니다.

1. 시작 단계 (150 명 미만). 물론 개발자는 자신의 소프트웨어를 실행해야합니다. 모두 스타트 업에서 그렇게합니다. 운영 팀이 없을 수도 있지만 그렇게해도 진행 속도가 빠르며 진행 속도가 너무 빠르기 때문에 다른 팀에서 신속하게 성공적으로 운영하는 데 필요한 지식을 전달할 수있는 방법이 없습니다. 성공하십시오.

2. 중간 규모의 비즈니스 (150 명 이상의 엔지니어, 단일 운영 팀) 이 단계에서 회사의 이탈이 너무 높아지기 시작합니다. 소프트웨어를 개발하는 엔지니어가 소프트웨어를 실행하기 위해 반드시 붙어있을 필요는 없습니다. 당신은 더 이상 모든 사람을 알지 못하며, 모든 사람이 사업에 참여하기 위해 효과적으로 의사 소통하기가 어렵습니다. 혼란으로 변하기 시작했습니다. 이 단계에서는 모든 팀이 소프트웨어를 운영해야하지만 반드시 운영 할 필요는없는 Google 모델로 전환하려고합니다. 처음에는 운영하지만 소프트웨어 구축의 큰 부분은 운영 팀이 운영에 서명 할 수있을 정도로 부하가 적은 지점까지 운영 비용을 줄이는 것입니다. 그런 다음에 만 수행됩니다.

3. 여러 사업부가있는 대기업 (각각 자체 운영 팀이 있음) :이 단계에서 모든 팀이 자체 서비스를 개발하고 운영하는 Amazon 모델로 돌아갈 수 있습니다. 각 사업 단위는 모두가 서로를 알아볼 수있을 정도로 작아야하므로 약 150 명 미만의 엔지니어와 각자 기본적으로 스타트 업으로 운영합니다. 아마존은 각 AWS 서비스를 다소 개별적으로 운영하며 그에 따라 작동합니다.

회사가 어느 단계에 있는지, 그리고 / 또는 그에 따라 움직이고 그에 따라 행동하는 단계를 파악해야합니다. "한 사이즈에 모두 맞는"솔루션은 없습니다.

내가 이런 명령을 받거나 무엇을 부를 것인지에 대한 나의 생각은 " What else would you expect?!?!" 와 같은 것이다 . 실수로 :

• 그것 없이는 살 수조차 없었고
• 나는 내 자신의 (개) 음식을 먹는 것을 좋아합니다.

좀 더 설명하겠습니다 ...

내 비즈니스 / 취미 / 열정은 scm 이며, 특히 메인 프레임 환경 에서 그렇습니다 . 그리고 내가 어디를 가든 (고객의 요구에 맞게 물건을 미세 조정하기 위해), 내가 계약에서 부과하는 첫 번째 요구 사항은 우리가 구현하는 시스템에 대한 모든 조정이 동일한 시스템을 통해 수행되어야한다는 것입니다. 그리고 그렇게하면 (실제로, 최대 반나절에 몇 시간이 걸리는 것처럼), 우리는 다음과 같은 이점을 얻습니다 (불완전한 목록).

• 시스템을 작동시키기 위해 수행 한 작업은 거의 문서화하지 않았습니다. 질문이 있으면 시스템에 질의하면됩니다 (고객의 도움없이 시스템을 질의하는 방법을 알려줍니다).
• X 개월 / 년 내에 전화를 걸면 (새 릴리스로 업그레이드 하시겠습니까?) 이전에 "I"가 무엇을했는지 알고 (기억하십시오) (내가 신뢰하는 유일한 것은 시스템에서 알려주는 것입니다. 나에게 상기시켜줍니다).
• 고객에게 사이트에서 특정 작업을 수행하는 방법 (이름 지정 규칙을 기억하기 어렵다)에 대해 한 번만 물어 보거나 "시스템"(필요하지 않은)에 필요한 권한을 부여하도록 설득해야합니다.
• 넌 continuously생산 ... 자신의 시스템을 품질 보증 테스트. 버그, 논리적 오류 또는 누락 된 기능 (및 그렇지 않은 기능)이 발생할 수 있습니다. 그리고 그들은 최대한 빨리 생산성을 높이기 위해 최대한 동기를 부여합니다.
• ... 원하는 경우 12 가지 이유를 추가 할 수 있습니다 ...

그러나 집에서 직접 시도하기 전에 피해야 할 함정에 유의하십시오.

• 단 하나의 "예외"(일명 회사의 관리자 / 소유자) 만 파티를 망칠 수 있기 때문에 모든 사람 이 파티에 참여하기 를 원합니다 (시스템 사용). 시스템을 묻거나 사용하지 않고). 이 경우 발견하는 데 며칠이 걸릴 수 있습니다 ...
• 신규 사용자는이 (신규) 시스템을 사용함으로써 이전에 사용했던 것과 비교하여 작업을 완료하는 데 시간이 더 걸린다고 불평 할 수 있습니다. 그리고 그것이 의미가있는 곳이라면 어디에서나 일을 마치기 위해 늦게 변명 할 것입니다. 이 시점에서 프로젝트 / 시스템이 책임을 져야 할 수 있으므로 최고 경영진이 당신을 다루는 것이 좋습니다.
• 자신의 시스템을 알고 필요에 맞게 시스템을 구성하는 방법을 알고 있어야합니다. 샘플 (내 경우) : 운영 환경을 사용하여 실험 환경에 전달하고 다른 방법으로 전달하지 않도록 시스템을 구성하려고합니다 ... 과거에 이런 일이 발생했습니다 ... 테스트 시스템을 사용하여 보안 수준이 높은 환경에 제공합니다.