IT/모바일
제공 : 한빛 네트워크
저자 : J. Paul Reed
역자 : 김인범(http://revolutionist-inbum.tistory.com)
원문 : Process Is Not a Four-Letter Word
올바른 방식의 표준화는 당신의 정신건강을 지키고 문화를 향상시킬 수 있다.
프로세스("Process")는 많은 소프트웨어 개발자, 운영 엔지니어, 시스템 관리자, 그리고 심지어 매니저도 기꺼이 싫어하는 것이다.
그것은 종종 유용한 도메인은 거대한 규모의 기업의 벽 속에 있거나 누구도 본 적 없는 위키(사용자들이 내용을 수정, 편집할 수 있는 웹사이트)에 존재하는, 생산성을 저해하고, 혁신을 억누르는 괴물로 간주된다.
나는 항상 매력적인 프로세스에 대한 혐오를 느꼈고, 지금은 구성 관리와 버전 제어가 디봅스(DevOps) 운동의 핵심 원칙이 된 것에 대해 더욱 혐오감을 느꼈다. 이런 도구들의 주 목적은 재현가능성, 신뢰성, 그리고 이러한 활동들의 표준화를 향상시키기 위해 소프트웨어 개발 및 운영을 위한 구조를 제공하는 것이다.
디봅스 데이(DevOpsDays)에서 나는 항공에서 배울 수 있는 교훈들을 소프트웨어 개발과 운영 맥락에서 살펴보는 강연을 진행했으며, 표준화는 이때 진행된 강연인 "Is Your Team Instrument Rated"에서 논의된 행위 중 하나이다.
그 강연에서, 나는 온 세계를 횡단하는 델타 항공이 미국 내를 비행하는 것만큼 꽤 많은지를 확인하기 위해(안전 및 운영 관점에서, 어쨌든 간에) 사용된 프로세스들이 국가 공역 체계(National Airspace System)에서 어떻게 조직하고 묘사하였는지를 살펴보았다.
프로세스와 표준화에 대한 당신의 조직의 접근방식을 재검사 하기 위해 시간을 투자하는 것은 단지 큰 항공사가 즐길 수 있는 이점을 실현시키는 도구는 아니다. 그것은 그들의 일을 생각해보고 최적화하기 위해 무엇이 엔지니어에게 중요한 것으로 간주되는 것인지 기록하고 협의하는 동안 당신의 엔지니어링 부서의 문화를 평가하는 방법이다.
따라서, 그것은 규정하기 힘든 디봅스 문화를 향해 변화를 시작하는(또는 지속하고 있는) 유용한 연습이다.
절차로 시작하지 말라
공항에 대한 접근 절차를 문서화 할 때, 연방 항공국(FAA)은 그들의 첫 번째 원칙에서 하나하나 씨름하지 않는다.
그들은 내가 운영상의 기초요소라 부르는 문서("TERPS"라 불린다)를 가지고 있다.
TERPS는 각 접근 절차가 준수해야 하는 요구 사항에 대한 길고 복잡한 리스트이며, 절차가 요구사항을 충족하지 않을 때, 그 접근에 대한 서술은 명시적으로 기록되어야 한다, 예를 들어 두 개의 내비게이션 수신기가 요구되거나 특정 온도 범위 내에서만 승인되는 경우이다.
당신의 운영상의 기초요소와 운영상의 절차를 구별해 내는 것은 당신의 조직에게 중요한 공학적 가치를 기록하는 것을 시작하는 데 있어 중요한 기술이다. 상이한 인공물을 처리하는 배포 문제를 생각해보자. 한 팀은 RPMs 를 사용하고, 다른 팀은 tarball을 그리고 또 다른 팀은 .jars의 zip 파일을 사용한다. 우리 중 많은 이들이 정확한 anti-pattern(흔히 쓰이지만 효과적이지는 않은 형태)으로 처리하고 그 문제와 그것이 유발하는 복잡성을 알고 있다.
문제를 해결하기 위한 운영상의 기본요소는 "인공물은 출판되고-배포는 오로지 관리하고-단일 패키지 형태" 를 진행하는 중 어느 시점이 될 수 있다. 이는 "우리는 모두 RPMs와 Yum 저장소를 사용하고 있다"는 것과는 다를 수 있다.
구별은 의미가 있을 수 있지만, 그렇지는 않다. 그것은 다른 유형의 생각을 촉진시킬 수 있다. 엔지니어가 문제 해결을 요청 받았을 때, 우리는 종종 해결책을 지역적으로 잡고, 지역화의 관점을 통해 최적화를 수행한다. 본질적으로 아무 문제 없지만(사실 그것은 효율적이다), 국지적으로 최적화된 해결책들은 시간이 지남에 따라 상당히 치명타가 될 수 있는 시스템 전체의 불일치와 비효율성을 만들어 낼 수 있다.
일련의 기본요소들이 균일함으로 우리의 구성요소들을 설계하도록 촉진하고, 엔지니어로서 시스템 레벨에서 제시하거나 설명해야 하는 다양한 사례들에 대해 생각하도록 돕는다. 위의 예는, 우리가 배포 파이프라인의 각각의 위치에서 입력과 출력을 생각하도록 만들고, 라이선스 등의 이유들로 어떤(아마도 상업적인) 구성요소가 표준의 패키지 형식을 사용할 수 없을 때와 같은 예외사항을 일으킬 수도 있다.
물론, TERPS가 최고 수준의 안개가 낀 샌프란시스코 아침에 특정 활주로에 안착하는 방법에 대해 응답할 수 없는 것처럼, 이러한 구성요소들을 정의하는 것이 당신의 팀을 그들 자신의 프로세스의 세부사항을 분류하는 일에서 면제시킬 수 있는 것은 아니다.
하지만 그것은 새로운 프로세스를 쓰기 위한 템플릿으로서, 프로세스에 대한 우려와 자세한 단계들을 구조화하는 방법에 대한 가이드로서, 그리고 그것이 쓰여진 후에 검증하기 위한 항목의 좋은 리스트로서, 그리고 일련의 단위 테스트로서 사용할 수 있다.
또한, 각 엔지니어가 첫 번째 원칙들로부터 운영 프로세스들을 만들어내지 않는 것은 그들이 (암묵적으로) 조직이 얻은 제도적 지식을 포함하고 있기 때문에 개발을 위해 충분한 시간을 가지고 있지 않고 일반적으로 안전할 것임을 의미한다. 그리고 물론 당신이 유지하고 기본 구성요소들을 논의할 수 있는 포럼을 사용하는 것은 그들이 서로 다른 건물이나 국가에 있을 때에도, 지식을 공유하고 협력하는 측면에서 팀에게 매우 좋은 방법이다.
마지막으로, 운영상의 기본요소들을 구축하는 것은 엔지니어가 이러한 기본 요구사항들의 편차를 표현하도록 한다. 6개월 뒤에 git blame을 사용하거나 나열한 엔지니어들을(개인적인 경험이나 경향) 저주하는 대신, 엔지니어가 결정을 내릴 때, 그들이 구축된 운영상의 기본요소들과 규범들로부터의 편차가 발생한 이유들을 문서화하도록 촉진한다.
이것은 그것을 코드로 함께 일할 미래의 개발자들과 운영 엔지니어에게 의사소통의 의도와 개발 맥락에서 효과적인 툴로 만들어준다.
비행, 훈련 그리고 커밋!
항공의 맥락에서 이 모든 것들이 크게 들리겠지만, 소프트웨어 개발의 어떤 영역이 이것에 적용되는가? 살펴보기 시작하기에 좋은 몇몇 영역들은 다음과 같다.
이러한 연습을 수행하는 데 있어 일반적인 불만은 종종 현대 소프트웨어 개발을 수용하기 위해 다소 딱딱하고 과민하게 보이는 "규칙들"의 목록을 생산하는 것이다. 그러나 그럴 필요는 없어 보인다. 연방항공국은 새로운 기술 개발을 설명하기 위해 규칙적으로 운영 기본요소들을 재 논의하고 있으며, 접근 절차는 공항과 영공 조건의 변화를 고려하여 업데이트를 받을 수 있다. 그리고 우리는 할 수 있다.
표준화를 그들의 문화의 일부로서 중히 여기는 조직은 그들의 기본 요구사항들에 대해 6개월 또는 매 50명을 고용하는 경우 중 먼저 발생하는 시기마다 재 논의를 하도록 계획해야 한다. 이것은 프로세스가 조직과 함께 진화하고 그것이 여전히 조직을 잘 유지시키고 있다는 것을 보장한다.
프로세스는 금기어가 될 필요가 없다
소프트웨어 개발의 세계는 나쁜 capital-P 프로세스로 가득 차 있고, 이에 대해서는 의심의 여지가 없다. 그것은 우리가 그 단어를 들을 때마다 한숨을 쉬고 눈을 굴리는 가장 큰 이유일 것이다.
그러나 어떻게 다른 분야가 생산, 구현, 그리고 자신의 조직 생태계 과정의 가장 중요한 문화적 적용을 접근하는지를 살펴봄으로써, 우리는 소프트웨어 개발 및 운영 맥락에서 우리의 프로세스 자체 개발에 대해 새로운 관점을 얻을 수 있다.
프로세스와 표준화는 비행기가 매일 무한히 작은 오류 비율로 세계를 누빌 수 있게 해주고, 공항이 안 좋은 기상조건에서도 안전하게 운영할 수 있게 해준다. 그리고 소프트웨어 개발 상점의 비밀 중 하나는 그들이 종종 디봅스의 Poster children ((특별한 질병 문제 등을 가진 아동들에 대한 도움을 구하는) 포스터에 나오는 아동들)의 역할을 한다는 것이다. 그들에게 프로세스는 나쁜 단어가 아니고, 표준화를 염두에 둔 연습은 그들의 코드와 승리하기 위한 기술 문화를 확장하기 위한 방법이다.
물론 회사의 운영 기본요소와 팀 프로세스를 표준화하는 것을 이해하는 것은 그들이 서로 통신할 수 없는 경우 거의 가치가 없는 것이다.
저자 : J. Paul Reed
역자 : 김인범(http://revolutionist-inbum.tistory.com)
원문 : Process Is Not a Four-Letter Word
올바른 방식의 표준화는 당신의 정신건강을 지키고 문화를 향상시킬 수 있다.
프로세스("Process")는 많은 소프트웨어 개발자, 운영 엔지니어, 시스템 관리자, 그리고 심지어 매니저도 기꺼이 싫어하는 것이다.
그것은 종종 유용한 도메인은 거대한 규모의 기업의 벽 속에 있거나 누구도 본 적 없는 위키(사용자들이 내용을 수정, 편집할 수 있는 웹사이트)에 존재하는, 생산성을 저해하고, 혁신을 억누르는 괴물로 간주된다.
나는 항상 매력적인 프로세스에 대한 혐오를 느꼈고, 지금은 구성 관리와 버전 제어가 디봅스(DevOps) 운동의 핵심 원칙이 된 것에 대해 더욱 혐오감을 느꼈다. 이런 도구들의 주 목적은 재현가능성, 신뢰성, 그리고 이러한 활동들의 표준화를 향상시키기 위해 소프트웨어 개발 및 운영을 위한 구조를 제공하는 것이다.
디봅스 데이(DevOpsDays)에서 나는 항공에서 배울 수 있는 교훈들을 소프트웨어 개발과 운영 맥락에서 살펴보는 강연을 진행했으며, 표준화는 이때 진행된 강연인 "Is Your Team Instrument Rated"에서 논의된 행위 중 하나이다.
그 강연에서, 나는 온 세계를 횡단하는 델타 항공이 미국 내를 비행하는 것만큼 꽤 많은지를 확인하기 위해(안전 및 운영 관점에서, 어쨌든 간에) 사용된 프로세스들이 국가 공역 체계(National Airspace System)에서 어떻게 조직하고 묘사하였는지를 살펴보았다.
프로세스와 표준화에 대한 당신의 조직의 접근방식을 재검사 하기 위해 시간을 투자하는 것은 단지 큰 항공사가 즐길 수 있는 이점을 실현시키는 도구는 아니다. 그것은 그들의 일을 생각해보고 최적화하기 위해 무엇이 엔지니어에게 중요한 것으로 간주되는 것인지 기록하고 협의하는 동안 당신의 엔지니어링 부서의 문화를 평가하는 방법이다.
따라서, 그것은 규정하기 힘든 디봅스 문화를 향해 변화를 시작하는(또는 지속하고 있는) 유용한 연습이다.
절차로 시작하지 말라
공항에 대한 접근 절차를 문서화 할 때, 연방 항공국(FAA)은 그들의 첫 번째 원칙에서 하나하나 씨름하지 않는다.
그들은 내가 운영상의 기초요소라 부르는 문서("TERPS"라 불린다)를 가지고 있다.
TERPS는 각 접근 절차가 준수해야 하는 요구 사항에 대한 길고 복잡한 리스트이며, 절차가 요구사항을 충족하지 않을 때, 그 접근에 대한 서술은 명시적으로 기록되어야 한다, 예를 들어 두 개의 내비게이션 수신기가 요구되거나 특정 온도 범위 내에서만 승인되는 경우이다.
당신의 운영상의 기초요소와 운영상의 절차를 구별해 내는 것은 당신의 조직에게 중요한 공학적 가치를 기록하는 것을 시작하는 데 있어 중요한 기술이다. 상이한 인공물을 처리하는 배포 문제를 생각해보자. 한 팀은 RPMs 를 사용하고, 다른 팀은 tarball을 그리고 또 다른 팀은 .jars의 zip 파일을 사용한다. 우리 중 많은 이들이 정확한 anti-pattern(흔히 쓰이지만 효과적이지는 않은 형태)으로 처리하고 그 문제와 그것이 유발하는 복잡성을 알고 있다.
문제를 해결하기 위한 운영상의 기본요소는 "인공물은 출판되고-배포는 오로지 관리하고-단일 패키지 형태" 를 진행하는 중 어느 시점이 될 수 있다. 이는 "우리는 모두 RPMs와 Yum 저장소를 사용하고 있다"는 것과는 다를 수 있다.
구별은 의미가 있을 수 있지만, 그렇지는 않다. 그것은 다른 유형의 생각을 촉진시킬 수 있다. 엔지니어가 문제 해결을 요청 받았을 때, 우리는 종종 해결책을 지역적으로 잡고, 지역화의 관점을 통해 최적화를 수행한다. 본질적으로 아무 문제 없지만(사실 그것은 효율적이다), 국지적으로 최적화된 해결책들은 시간이 지남에 따라 상당히 치명타가 될 수 있는 시스템 전체의 불일치와 비효율성을 만들어 낼 수 있다.
일련의 기본요소들이 균일함으로 우리의 구성요소들을 설계하도록 촉진하고, 엔지니어로서 시스템 레벨에서 제시하거나 설명해야 하는 다양한 사례들에 대해 생각하도록 돕는다. 위의 예는, 우리가 배포 파이프라인의 각각의 위치에서 입력과 출력을 생각하도록 만들고, 라이선스 등의 이유들로 어떤(아마도 상업적인) 구성요소가 표준의 패키지 형식을 사용할 수 없을 때와 같은 예외사항을 일으킬 수도 있다.
물론, TERPS가 최고 수준의 안개가 낀 샌프란시스코 아침에 특정 활주로에 안착하는 방법에 대해 응답할 수 없는 것처럼, 이러한 구성요소들을 정의하는 것이 당신의 팀을 그들 자신의 프로세스의 세부사항을 분류하는 일에서 면제시킬 수 있는 것은 아니다.
하지만 그것은 새로운 프로세스를 쓰기 위한 템플릿으로서, 프로세스에 대한 우려와 자세한 단계들을 구조화하는 방법에 대한 가이드로서, 그리고 그것이 쓰여진 후에 검증하기 위한 항목의 좋은 리스트로서, 그리고 일련의 단위 테스트로서 사용할 수 있다.
또한, 각 엔지니어가 첫 번째 원칙들로부터 운영 프로세스들을 만들어내지 않는 것은 그들이 (암묵적으로) 조직이 얻은 제도적 지식을 포함하고 있기 때문에 개발을 위해 충분한 시간을 가지고 있지 않고 일반적으로 안전할 것임을 의미한다. 그리고 물론 당신이 유지하고 기본 구성요소들을 논의할 수 있는 포럼을 사용하는 것은 그들이 서로 다른 건물이나 국가에 있을 때에도, 지식을 공유하고 협력하는 측면에서 팀에게 매우 좋은 방법이다.
마지막으로, 운영상의 기본요소들을 구축하는 것은 엔지니어가 이러한 기본 요구사항들의 편차를 표현하도록 한다. 6개월 뒤에 git blame을 사용하거나 나열한 엔지니어들을(개인적인 경험이나 경향) 저주하는 대신, 엔지니어가 결정을 내릴 때, 그들이 구축된 운영상의 기본요소들과 규범들로부터의 편차가 발생한 이유들을 문서화하도록 촉진한다.
이것은 그것을 코드로 함께 일할 미래의 개발자들과 운영 엔지니어에게 의사소통의 의도와 개발 맥락에서 효과적인 툴로 만들어준다.
비행, 훈련 그리고 커밋!
항공의 맥락에서 이 모든 것들이 크게 들리겠지만, 소프트웨어 개발의 어떤 영역이 이것에 적용되는가? 살펴보기 시작하기에 좋은 몇몇 영역들은 다음과 같다.
- 코드 라인 관리 : 기능 및 릴리즈 분기(branch)를 만들기 위한 표준 프로세스를 가지고 있는가? 예상 명명 규칙은 무엇인가? 병합(merge) 사례들은 정의되었는가? 중앙 저장소는 이러한 가이드라인을 따르는 푸시/커밋 유효성을 검사하는가?
이해하고 탐색하기 위해 저장소가 깨끗하고 쉽게 유지할 수 있도록 도울 뿐만 아니라, 코드 라인 관리와 관련된 기준은 다른 팀이 쉽게 동료가 작업하는 코드를 찾을 수 있도록 한다. 품질관리(QA) 및 운영(Ops) 조직 직원들은 개발자들과 협업할 때 어느 곳을 살펴봐야 할지를 알고 있다. 그들은 또한 당신이 실제로 코드가 존재하는 곳에 대한 가정을 할 수 있게(유효한!) 하는 자동화를 만들 수 있도록 한다.
여기에 당신의 프로세스가 기반이 되는 기본 구성요소는 당신의 저장소가 모두가 놀 수 있는 모래 박스 통이고 만약 목표가 모래성을 짓기 위해 함께 일하는 것이라면, 협력적으로 그것을 이루기 위한 방법을 위한 규칙이 필요하다는 것을 인지하는 것이다.(또한, 모래 던지기는 없다!)
- 배포 요구 사항 : 준비 또는 생산과 같은 환경에 들어가기 위한 어떤 인공물에 대해 필요한 것을 설명할 수 있는가? (그 리스트가 다른가? 그것이 꼭 달라야 하는가?)
그러한 질문들은 "운영 요구사항"이란 제목과 어울려 보이고, 그것들은 종종 개발자들과 운영 엔지니어들 사이에서 버려질 수 있는 지식들이고, 그들과 의사 소통하거나 대조를 하거나 그 정보를 기록하는 좋은 방법이 없기 때문에, 일반적으로 문제가 되는 부분이다. 표준화 연습은 이러한 문제점을 해결할 수 있는 좋은 장이다.
검증할만한 항목들은 모듈 또는 데이터베이스 스키마 버전(당신은 그것에 대해 버저닝을 했을 것이다, 그렇지 않은가?)을 기대한 대로 맞춰놓도록 하거나 특정 키/구성 값이 특정 환경들에서 오프(off) 상태가 되도록(또는 온(on) 상태) 보장하는 것을 포함한다.
한 번 문서화 되면, 단위 테스트는 실질적으로 당신의 배포 프로세스와 더 중요하게는 기대치 않은 변화가 생겼을 때의 반응에 대한 당신의 가정을 검증하기 위해 쓰여질 것이다.
이러한 연습을 수행하는 데 있어 일반적인 불만은 종종 현대 소프트웨어 개발을 수용하기 위해 다소 딱딱하고 과민하게 보이는 "규칙들"의 목록을 생산하는 것이다. 그러나 그럴 필요는 없어 보인다. 연방항공국은 새로운 기술 개발을 설명하기 위해 규칙적으로 운영 기본요소들을 재 논의하고 있으며, 접근 절차는 공항과 영공 조건의 변화를 고려하여 업데이트를 받을 수 있다. 그리고 우리는 할 수 있다.
표준화를 그들의 문화의 일부로서 중히 여기는 조직은 그들의 기본 요구사항들에 대해 6개월 또는 매 50명을 고용하는 경우 중 먼저 발생하는 시기마다 재 논의를 하도록 계획해야 한다. 이것은 프로세스가 조직과 함께 진화하고 그것이 여전히 조직을 잘 유지시키고 있다는 것을 보장한다.
프로세스는 금기어가 될 필요가 없다
소프트웨어 개발의 세계는 나쁜 capital-P 프로세스로 가득 차 있고, 이에 대해서는 의심의 여지가 없다. 그것은 우리가 그 단어를 들을 때마다 한숨을 쉬고 눈을 굴리는 가장 큰 이유일 것이다.
그러나 어떻게 다른 분야가 생산, 구현, 그리고 자신의 조직 생태계 과정의 가장 중요한 문화적 적용을 접근하는지를 살펴봄으로써, 우리는 소프트웨어 개발 및 운영 맥락에서 우리의 프로세스 자체 개발에 대해 새로운 관점을 얻을 수 있다.
프로세스와 표준화는 비행기가 매일 무한히 작은 오류 비율로 세계를 누빌 수 있게 해주고, 공항이 안 좋은 기상조건에서도 안전하게 운영할 수 있게 해준다. 그리고 소프트웨어 개발 상점의 비밀 중 하나는 그들이 종종 디봅스의 Poster children ((특별한 질병 문제 등을 가진 아동들에 대한 도움을 구하는) 포스터에 나오는 아동들)의 역할을 한다는 것이다. 그들에게 프로세스는 나쁜 단어가 아니고, 표준화를 염두에 둔 연습은 그들의 코드와 승리하기 위한 기술 문화를 확장하기 위한 방법이다.
물론 회사의 운영 기본요소와 팀 프로세스를 표준화하는 것을 이해하는 것은 그들이 서로 통신할 수 없는 경우 거의 가치가 없는 것이다.
TAG :
이전 글 : DIY 보조 배터리, 뱃박스(Bat Box) 만들기
최신 콘텐츠