천객만래 [千客萬來] (It has an interminable succession of visitors)

품질경영(Quality Management)

QA (Quality Assurance, 품질보증)

제품을 생산하기 위한 전 과정에 대한 보증을 하는 것. 직무를 말합니다.

, 제품의 개발에서부터 생산되고 출하 되기 까지의 전 과정을 검사하고 문서화 하는 작업.

ITP(검사및시험계획서), 절차서

QC (Quality Control, 품질관리)

각종 시험을 통해 제품의 품질을 어느 수준으로 관리하는 직무.

, 제품이 생산되면 생산된 제품이 일정 수준의 성능을 유지한다는 것을 전제로

시험성적서를 작성하는 것.

QIP(품질시험계획서), 제품명세서

Posted by SB패밀리

댓글을 달아 주세요

소프트웨어 개발주기

확인(Verification) - 제품을 올바르게 개발하고 있는가? Need

소프트웨어 개발 주기에서 주어진 단계에서의 생산품이 이전 단계에서 수립된 요구들을 수행하는가를 결정하는 과정.

프로그램 정확도의 형식 증명.

항목들, 프로세스들, 서비스들, 또는 문서들이 명시된 요구들을 따르는지 재검토하고 조사하며 시험, 검사, 감사 및 문서화하는 행위.

검증에는 주기 검증과 형식 검증의 두 가지 형태가 있다. 주기 검증은 개발 주기의 특정 단계에서 제작된 생산 제품이 그 이전 단계에서 설정한 규격들을 어느 정도 충족시키는지를 결정하는 과정이다. 형식 검증은 원시 부호가 규격에 맞게 작성되었는지를 수학적으로 엄격하게 증명하는 것이다

보증,검증(Validation) - 올바른 제품을 개발하고 있는가? Procedure

소프트웨어에 대한 요구 조건에 응하고 있는 것을 확인하기 위해 소프트웨어 개발공정의 마지막에 소프트웨어를 평가하는 공정.

소프트웨어개발과정의 최종 단계로써, 소프트웨어가 요구된 바와 합치되는지를 평가하는 일.

소프트웨어 타당성 검사(Software Validation)

 

 

 

Posted by SB패밀리

댓글을 달아 주세요

검증(Validation)

올바른 제품을 만들고 있는가? WHAT

QIP(Quality Inspection Plan)

품질시험계획서(제품명세서)

기자재 제작업체가 기기제작에 착수하기 전에 검사품명, 제작공정별 검사  항목,     적용규격, 검사예정일, 검사장소 등을 명시하여 검사를 효과적으로 수행하기 위하여 제작업체가 작성하여 발주자가의 승인을 받으며 시험 및 검사가 공장에서 이루어지는 공장 QIP와 발전소 또는 건설현장에서 이루어지는현장 QIP로 구분됩니다.

   - 검사방법은 “R, W, H” 가 있으며, 자세하게 설명하면 다음과 같습니다.

   R(Review Point) : 공정 중 시험환경, 절차 및 판정기준 등의 시험요건과 규격 및 성능이 계약규격에 만족되는지를 확인하기 위하여 점검하는 행위입니다.

   W(Witness Point) : 공정 중 검사자의 입회를 받도록 결정한 시점으로,입회검사가 불가능할 경우 다음 공정으로 진행시킬 수 있으나, 반드시 입회불가 통보를 받은 후에 진행하여야 합니다.

   H(Hold Point) : 공정 중 검사자에 의한 검사 또는 입회를 필요로 하는 중요단계로서 검사에 합격하지 않고는 다음 공정으로 진행하지 못하도록 결정한 검사점을 말합니다.

 

확인(Verification)

올바르게 제품을 만들고 있는가?  HOW

ITP(Inspection Test Plan)

검사및시험계획서(시험절차서)

공정 중 실시하는 검사항목에 대한 적용범위, 적용기준 및 표준, 시험 및 검사 항목, 항목별 시험검사 절차, 판정기준 등 시험 및 검사수행에 필요한 내용을 상세히 기술한 서류를 말합니다

 

 

품질관련 필수용어 필수용어 참조

Posted by SB패밀리

댓글을 달아 주세요

[IT/개발] DevOps, 개발과 운영의 새로운 문화

2012년6월20일


출처: http://dev.paran.com/2012/06/20/devops-new-trend-in-developement-and-operations/

DevOps, 개발과 운영의 새로운 문화

kth DevOps팀 김동수

요즘 IT 관련 아티클에 새롭게 그리고 자주 등장하는 단어로는, NoSQL, Cloud, Big Data 그리고 DevOps 등이 있습니다. 이 글에서는 그 중 개발과 운영에 있어 중간적인 입장에서 역할을 수행하는 방법론인 DevOps 에 대해서 이야기 하고자 합니다.

DevOps 에 대해서 이야기 하기에 앞서, DevOps 를 소개하는 자료에서 자주 등장하는 3개의 서비스를 간단히 살펴 보겠습니다.

Netflix 는 미국에서 BlockBuster 라는 거대한 오프라인 영화 렌탈 체인을 함몰시킨 VOD 회사로 이 많은 트래픽을 감당하기 위해 AWS 에 10,000개 이상의 인스턴스를 10명의 DevOps 팀으로 운영하고 개발을 지원하고 있습니다.

Flickr 는 2004년 2월부터 서비스 하고 있는 사진 중심의 SNS 서비스로, 초당 40,000 장의 사진이 업로드 되고 있습니다. 거의 모든 것을 자동화하고, 개발과 운영 각자만의 문화를 바꾸어, 서로 협력하여 하루에도 10번씩 배포할 수 있도록 하였습니다.

fotopedia 는 2006년 파리에서 설립된 20여명의 직원으로 구성된 기업으로, 인간 중심의 사진 이라는 모토로 flickr 와 Wikipedia 를 섞어 놓은 서비스를 제공하고 있습니다. 일일 1억 5000만의 페이지뷰를 보유하고 있습니다. AWS 클라우드에 시스템을 구축하여 1개의 MySQL DB 와 4개의 MongoDB Cluster 로 운영되고 있으며, 매일 평균 3개정도의 hot-patch 를 배포하고 있습니다.

이들 서비스를 제공함에 있어 공통적으로 개발과 운영에 적용한 방법론이 DevOps 입니다. 위의 세 서비스 이외에도 DevOps 방법론을 적용하고 서비스 하는 곳은 점점 더 많아지는 추세입니다. 그럼 DevOps 에 대해서 좀 더 자세히 이야기 해 보겠습니다.

“DevOps” 는 무엇인가?

IT 에 몸을 담고 있는 분이라면 “DevOps” 라는 단어만 보더라도 무엇이 합쳐져서 만들어진 용어인지 쉽게 짐작할 수 있을 것입니다. 짐작되는 대로 Development (개발) 와 Operations (운영) 의 두 단어가 합쳐진 합성어입니다.

영문 Wikipedia 에서는 DevOps 를 다음과 같이 정의하고 있습니다.

DevOps라는 합성어는 소프트웨어 개발자들과 IT 종사자들 사이의 의사소통, 협업, 융합을 강조한 소프트웨어 개발 방법론이며, 소프트웨어 개발과 IT 운영간의 상호 의존관계에 대한 산물이다. DevOps 는 조직에서 소프트웨어 상품과 서비스를 신속히 생산하는 것에 도움이 되는 것을 목적으로 한다.

즉, 소프트웨어를 만들어 내는 개발자, 잘 동작하도록 운영하는 운영자, 그리고 그 소프트웨어의 품질을 관리하는 품질관리 조직 개발조직이, 소프트웨어를 개발, 빌드, 테스트, 배포, 운영에 이르는 사이클을 신속하게 진행할 수 있도록, 업무 프로세스를 정의하고, 각 조직간의 역할을 조율하고, 그 프로세스들을 자동화하여 효율적으로 운영되도록 하는 역할과 방법론을 DevOps 라고 할 수 있습니다.

< devopsdays 2009, from http://devopsdays.org/ >

DevOps 용어는 2009년 벨기에에서 시작되어, 인도, 미국, 브라질, 오스트리아, 독일, 스웨덴 등지에서 개최되고 있는 “Devops Days” 행사로부터 보급되기 시작했습니다.

< devopsdays 2012 사이트>

이 행사는 2009년 이후 해마다 세계 여러 나라에서 개최되고 있으며, 2012년에는 일본의 도쿄, 호주의 시드니, 미국의 마운틴뷰, 인도, 이탈리아에서 개최됩니다. 6월 28~29일 마운틴뷰에서 DevOps Days Mountain View 2012 행사가 열리고, 저희 DevOps 팀에서도 참석할 예정입니다.

“잦은 배포의 효과”

DevOps 를 이야기 하면서, 애자일 방법론이 빠질 수는 없습니다.

그 이유는 다음의 그림에서 애자일과 워터폴 방식에서의 위험도의 변화차이로 설명할 수 있습니다.

<잦은 릴리스로 인한 위험의 하향 균등화, from http://en.wikipedia.org/wiki/DevOps#Devops_Days>

애자일 방법론을 적용하면 작게 그리고 잦은 릴리즈를 하게 되어, 변경되는 범위가 작아지므로, 릴리즈에 따른 위험도가 낮게 균등해 집니다. 반면에, 전통적인 워터폴 방법론을 적용하는 SI 프로젝트와 같은 경우 긴 텀을 두고 한번에 여러 기능을 개발하고 배포하므로 그 추가되는 기능만큼 위험도가 크지게 됩니다.

이렇게 잦은 주기로 반복적으로 배포를 매끄럽게 수행하기 위해서는 만족되어야 하는 것이 있습니다. 첫째, 잦은 개발과 버그 픽스를 할 수 있고, 공유할 수 있는 소스코드 버전 관리 시스템이 있어야 합니다. 이것이 없다면, 동시에 여러 버전을 운영하는 환경에서는 잦은 개발을 할 수 없게 됩니다. 둘째, 빌드, 테스트, 배포 단계를 가능한 한 자동화 해야 합니다. 빌드, 테스트, 배포 단계를 수작업으로 하게 된다면, 실수가 있을 수 있고, 각 단계마다 많은 시간이 반복 소요되므로 효율이 낮아지므로, 자동화를 통해 효율성을 확보해야 합니다. 그리고, 셋째 서비스를 개발하는 개발 조직과 운영해 가는 운영조직간의 매끄러운 협업이 필요합니다.

“개발과 운영 조직”

<Wall of Confusion, from http://dev2ops.org/blog/2010/2/22/what-is-devops.html>

잦은, 반복적인 배포를 하기 위해서는 개발과 운영의 협업이 매우 중요합니다.

개발자는 새로운 기술을 소프트웨어에 적용해서 개발하고, 실험하고, 배포하길 원합니다. 반면, 운영자는 잘해야 본전이므로, 서비스는 절대 멈추어서는 안되기 때문에 서비스의 안정성에 우선하여 보수적인 입장에서 접근하게 되는 서로간의 장벽이 존재합니다. 물론, 각자의 역할을 충실히 임하고 있으니, 어느 누가 잘못된 것은 아닙니다.

규모가 아주 큰 금융이나 통신 SI 프로젝트 인 경우 배포해야 할 시스템도 많고, 개발할 요구사항 목록도 적게는 수백에서 수천 라인을 넘어가는 프로젝트에서는 개발자와 운영자는 각자의 명확한 역할 분담과 함께 책임이 주어져야 합니다. 그러나, 잦은 배포를 하는 인터넷 서비스와 모바일 서비스를 하는 조직에서도 한정된 리소스 내에서 위와 같이 각자의 역할을 분담해서 개발자는 개발만, QA 조직에서는 테스트만, 운영 조직에서는 운영에만 한정되도록 역할을 분담하여 서비스를 운영한다면, 조직간의 시너지를 얻을 수 없고 자원 낭비와 품질에 문제를 가져올 수 밖에 없습니다.

운영자는 서비스하는 어플리케이션에 대한 아키텍처와 데이터저장소, 프레임웍, 프로세스에 대한 이해를 가져야 하고, 개발자 또한 어플리케이션이 돌아가고 있는 서버와 클라우드 환경에 대해서 이해를 하고 있어야 합니다.

그럼, 이 글의 처음에 소개된 3개의 인터넷 서비스 중 Flicker 에서는 어떻게 두 조직을 융합하고 있는지 예를 들어 보도록 하겠습니다.

“운영자 처럼 생각하는 개발자, 개발자 처럼 생각하는 운영자”

개발자와 운영자는 서로 존중하며, 신뢰해야 합니다. 다른 사람들의 전문성과 의견, 책임을 인정해야 합니다.

운영자는 새로운 기능에 있어서, 개발자를 믿어줘야 하고, 개발자는 운영자가 제안하는 인프라의 변화를 믿어줘야 합니다.

서로 숨기지 말고 투명해야 합니다.

개발자는 자신의 코드가 어떠한 영향을 주는지 알려야 하고, 운영자는 개발자에게 시스템에 들어갈 방법을 제공해야 합니다.

그리고, 서로에게 손가락질을 금지해야 합니다. 서로를 비난하고, 시작부터 손가락질 하기 시작하면 다음의 “손가락질 프로세스” 와 같이 숨기기에 급급하여 가장 먼저 해야 할 문제 파악이 뒤쳐지게 됩니다.

반면 아래의 “생산적인 프로세스” 에서는 가장 먼저 문제부터 파악하고, 신속히 장애를 수습하여 정상적인 서비스와 정상적인 삶으로 복귀할 수 있습니다.

“개발, 품질관리, 운영의 교집합”

<개발, 품질관리, 운영의 교집합, from http://en.wikipedia.org/wiki/DevOps#Devops_Days>

DevOps 는 신뢰성, 보안성 그리고 개발과 배포 사이클을 더 빠르게 개선하기 위해 배포, 테스트, 세부기능 개발, 릴리즈 관리를 목표로 합니다.
이러한 면에서 개발, 품질관리, 운영의 교집합이 되는 부분에 위치한다고 볼 수 있습니다.

“결론”

DevOps 는 툴이 아니라 사업적인 목표를 개발과 운영 조직이 서로 협업하여 같은 목표로 나아갈 수 있도록 하는 문화이고 일하는 방식입니다

Posted by SB패밀리

댓글을 달아 주세요