직원이 부족한 데브 옵스 팀의 전형적인 징후와 신호는 무엇입니까? 팀에 새로운 추가 요청을 어떻게 정당화 / 설명 하시겠습니까?

질문을 일반적인 것으로 유지하고 싶지만 여기에 몇 가지 추가 정보가 있습니다.

현재 팀으로 2 명의 DevOps 전문가가 협력하고 있지만 제품의 수요와 수량 및 복잡성이 증가하고 있습니다. 팀에 새로운 추가를 요청하려고하는데, 왜 이것이 좋은 아이디어인지 설명하고 증명하는 데 어려움이 있습니다.

팀원이 부족 하다고 느끼는 데는 네 가지 주요 이유가 있습니다 .

1. 열악한 조직 및 작업 계획
2. 다른 사람이해야 할 일을하는 것
3. 전혀 수행해서는 안되는 작업
4. 실제로 인력 부족

처음 세 가지 점을 검토하면서 시작하십시오. 첫 번째 방법에 대한 아이디어 는 Phoenix 프로젝트 를 참조하십시오 . 자신이해야 할 일과해야 할 일이 있는지, 아니면 자신이해야 할 일을 할 수있는 사람이되게해야하는 경우, 모든 사람에게 도움이되는 모든 일에 대해 스스로에게 물어보십시오. 이렇게하면 모든 작업이 필요한 이유에 대한 문서가 제공됩니다.

다음으로 Phoenix 프로젝트에서 언급 한 4 가지 유형의 작업을 검토하십시오.

1. 비즈니스 프로젝트 -조직의 다른 팀을 위해 수행하는 작업
2. 내부 프로젝트 -향후 작업을보다 쉽게하기 위해 수행하는 작업
3. 정기 유지 보수 -조명을 유지하기 위해 수행하는 작업
4. 계획되지 않은 인터럽트 -문제가 발생하여 수행하는 작업

팀의 작업이 지속 가능한 경우, 네 개 각각에 대략 같은 시간을 소비하게됩니다. 계획되지 않은 작업이 시간의 50 % 가까이에 다 다르기 시작하면 분명히 직원이 부족하다는 신호입니다.

계획되지 않은 작업보다 시간의 25 %에 도달하기 전에 한 사람 정도를 유지하도록 고용 할 수 있어야합니다. 그렇지 않으면 한 사람이 떠나면 전체 팀을 다시는 회복 할 수없는 꼬리 줄로 보낼 수 있습니다. 사람과 기술의 초과 프로비저닝은 동일한 이유와 이점이 있습니다.

배경 : 현재 인프라 및 개발자에 대한 지원을 제공하는 것 외에도, 스프린트 및 새로운 프로젝트 내에서 개발 팀을 지원하는 것 외에도 달성하고자하는 목표에 대해 DevOps 팀으로서 월간 계획을 수립합니다. 그러나 한 달 동안 우리는 종종 수행하고 개선해야 할 추가 사항을 발견하여 백 로그에 추가합니다. 우리는 또한 우리의 범위를 벗어난 다양한 다른 것들을 책임지고 지원하지만, 우리가 할 수 있었던 사업을 지원합니다 :)

답변 : 많은 유지 보수, 특히 유지 보수 작업으로 넘어 가지 않거나 연기하지 않는다는 것을 알게 되 자마자 나는 이것이 좋은 경험이라고 생각합니다. 또한 DevOps 팀이 얇아 질수록 더 많은 새로운 프로젝트와 개발 팀이 확산 될수록 더 많은 사람들이 필요하게됩니다.

매일 매일 과제를 완수하는 것이 쉽지만, 한 달에 한 번이라도 물러서서 이것을 평가하는 것이 중요하다고 생각합니다.

실제로이 문서의 SRE 핸드북에서 페이지를 가져옵니다. DevOps 전문 분야는 조직과 수평 적으로 성장하기위한 것이 아닙니다. 오히려 일이 끝나지 않았다는 것을 알면 개발자가 셀프 서비스를 제대로 수행 할 수 없다는 신호입니다.

프로세스를 평가하고 일반적으로 인정되는 DevOps 원칙에 어떻게 부합하는지 그리고 업계 모범 사례를 얼마나 잘 따르고 있는지 확인하십시오.

이 두 팀이 프로젝트에서 프로젝트로 이동하고 거기에서 DevOps 항목을 설정한다고 가정합니다 (CI / CD 파이프 라인 생성, 다른 개발자가 Dockerfile 생성 또는 기타 사용중인 기술 지원). 즉, http://web.devopstopologies.com/에 따라 3, 4, 5 또는 6을 입력 하십시오 .

이 경우 부족한 징후는 단순히 두 가지 작업량이 너무 많음을 나타냅니다. 서비스를 요청하는 프로젝트가 너무 많습니다. 너무 많은 티켓; 시간 외에; 스트레스, 소진. 이러한 요소는 책임있는 리더십이 더 많은 역량을 추가 할 수있는 충분한 이유가되어야합니다. 여기에 DevOps 고유의 표시가 보이지 않으며 단지 인력이 부족한 기능 일뿐입니다.

무언가를 바꾸는 또 다른 징후는 당신이 좋은 모습을 취하고 모든 DevOps 노하우가 그 두 남자 / 여자에 집중되어 있고 다른 모든 사람들이 기댈 때 "DevOps 사일로"를 만드는 것을 알면 이 두 가지는 "DevOps 수행"입니다. 이것이 DevOps의 요점이 아닙니다. 이 경우 문화적 측면에 대해 생각하고 다른 팀의 전도사 / 교사 / 코치가되도록 수정하십시오.

두 경우 모두, DevOps가 처음에 좋은 이유는 더 좋은 이유 (일반적인 좋은 것)가 상위 관리자에게 명확해야합니다. 해당 메시지를 전달할 수없는 경우 팀의 작업을 정규 Dev / Ops로 이동하여 규모를 줄이십시오 (어쨌든).

DevSecOps가 팀이 아니라 사고 방식이라는 인상을 받았습니다. Dev (Sec) Ops "팀"이 있다면 잘못하고 있습니다. 두 명의 "DevOps 엔지니어"를 두는 것 주위를 둘러 보려고합니다. 함께 "DevOps 팀"이라고 부릅니다.

우리는 개발 팀, SCM, 애플리케이션 보안 및 시스템 엔지니어가 모두 코드 및 구성 / 시스템 변경을 스테이징 또는 프로덕션으로 지정된 엔드 포인트로 푸시하기위한 빠른 배치 / 릴리스 모델을 위해 협력하고 있습니다.

이것은 "devOps"엔지니어와 아무 관련 이 없습니다 .

작업 그룹화

과거에 비슷한 상황에서 사용한 접근법은 4 가지 주요 작업 그룹으로 팀의 작업을 구성하고 해당 작업을 완료하기 위해 2 개의 FTE (Full Time Equivalents)에 해당하는 작업을 할당하는 것입니다. 우리의 경우 메인 프레임 환경에서 SCM 헬프 데스크를 실행하는 것과 관련이 있었고 약 300 명의 개발자가이 두 FTE의 모든 종류의 도움말 / 중재를 요청했습니다. 작업 그룹은 4 가지 가능한 우선 순위로 구성됩니다.

• 우선 순위 1과 2의 과제를 완료 해야 합니다 (변명 / 협상 불가)
• 우선 순위 3 작업은 " 시간이 허락 되는 즉시 "완료되어야 합니다.
• 우선 4 작업 "완료되어야하는 경우 시간이 허락을".

각 4 개 그룹의 작업 종류에 대한 자세한 내용은 계속 읽으십시오 ...

작업 설명

우선 순위 1-헬프 데스크 운영

• 쉽게 접근 할 수 있고 항상 이용할 수있는 전문가에 의해.
• 업무 시간 동안 전화, 이메일 또는 발권 시스템을 통해.
• 사전 정의 된 SLA를 준수합니다.
• 모든 통화를 주기적으로보고하여 모든 헬프 데스크 통화의 ITIL 기반 등록.
• 중요한 문제에 대해 긴급 사용자 정의 (해결 방법)를 적용하십시오.

우선 순위 2-감시 서비스

• 연중 무휴 24 시간 전화 가능 여부.
• 사전 정의 된 SLA를 준수합니다.
• 모든 감시 의무 통화보고.
• 필요한 경우 관리 에스컬레이션.

우선 순위 3-정기 유지 보수

• 관리.
• 신청 탑승.
• 가정.
• 성능 향상
• 공간 관리.
• 자원 소비 조정
• 헬프 데스크 전화 및 / 또는 업무 감시 개입 횟수를 줄이기 위해 사용자 정의 기능 향상을 제안하십시오.

우선 순위 4-수정 사항 및 개선 사항

• 사용자 문서를 작성하고 유지 보수하십시오.
• 새로운 사용자 정의에 대한 QA 테스트.
• 개선 요청을 개발하고 구현하십시오.
• DRP 테스트에 참여하십시오.

평가

위에서 설명한 접근 방식을 사용하는 경우 다양한 일이 발생할 수 있습니다.

• 팀원이 부족하면 대부분의 시간이 우선 순위 1 및 2 작업으로 이동하지만 우선 순위 3 작업을 얻는 데 시간이 걸릴 수 있습니다. 우선 순위 4 작업은 기아로 고통받을 수 있습니다. 그 작업).
• 우선 순위 4 개 작업에 " 투자 " 할 수 있는 시간이 많을수록 우선 순위 1 및 2 개 작업에 필요한 시간이 더 많이 줄어들어 가용 예산 2 개에 해당하는 시간을 더 많이 투자 할 수 있습니다. "우선 순위 4 개 작업에서.
• 잠시 후 우선 순위 1 및 2 작업 수가 어떻게 감소하는지 놀랄 것입니다. 이러한 작업에 대해 적절한보고를 수행하면 경영진이 듣고 싶어하는 것입니다. 우리의 경우 그 숫자는 약 300 / 월에서 100 / 월 아래로 떨어졌습니다 ...
• 그러나 2 개의 FTE가 우선 순위 4 개의 과제를 수행 할 시간이없는 것처럼 보이면 경영진에 대한 완벽한 설명과 증거가 있습니다.