생명에 중요한 시스템을 통한 혁신

모든 기업에는 "중요한" 인프라가 있습니다. 일반적으로 이는 시스템이 오프라인 상태가 되면 기술자가 다시 가동할 수 있을 때까지 비즈니스의 일부(또는 전체)가 중단된다는 것을 의미합니다. 이는 대규모 소프트웨어, 하드웨어 또는 네트워크 업그레이드가 필요한 경우에 자주 발생합니다. 새로 배포된 시스템에 시스템 오류를 유발하는 예기치 않은 버그가 포함되어 있거나 사용자가 새 시스템에 익숙하지 않아 실수를 하고 기술자가 할 수 있을 때까지 생산성이 중지됩니다. 배포 버그를 해결하거나 사용자를 교육하십시오. 대부분의 경우 가동 중지 시간이나 생산성 감소는 신기술의 향상된 성능과 효율성을 약속하는 대가로 받아들일 수 있는 위험이지만 보편적인 것은 아닙니다. 대부분의 기업은 많은 수익에 대한 위험을 감수하거나 고객에게 적대감을 주지 않고 일정 수준의 가동 중지 시간을 감당할 수 있습니다.

그러나 수정해야 하는 시스템이 생명에 중요한 시스템 인 경우 생명 안전이 시스템을 안정적으로 사용할 수 있어야 하는 경우 어떻게 됩니까?

이 기사는 우리가 대부분의 시간을 보내는 전통적인 소프트웨어 개발에서 벗어나 생명에 ​​중요한 시스템의 인적 요소를 살펴봅니다. 이 주제에 대한 제 생각은 911 구급차 서비스의 정보 기술 이사, 국제 인도주의적 재난 대응 조직의 기술 전문가 및 박사 학위를 받은 경험에서 비롯됩니다. 매사추세츠 공과 대학에서 인간 시스템 통합을 이수했습니다.

시작하기 전에 이것이 귀하와 관련이 있는 이유를 설명하고 싶습니다. 당신의 프로젝트가 실제로 생명에 중요한 시스템을 포함하고 있다는 것은 분명하지 않을 수 있지만, 당신이 생각하는 것보다 훨씬 가능성이 높습니다. 다음은 모두 자격이 있으며 셀 수 없이 많은 주제가 있습니다.

• 자동차. 차량 제조업체 또는 해당 공급업체와 프로젝트를 진행 중이신가요? 자율주행차 스타트업이 대학을 졸업했다? 자동 제동, 순항 제어, 차선 제어, 컴퓨터 비전, 장애물 인식, 전자 엔진 제어 모듈 등. 이들 모두는 생명에 중요한 시스템이며 고장은 치명적일 수 있습니다.
• 비행. 30,000피트 상공에서 거의 모든 시스템 오류가 생명에 치명적일 수 있습니다. 최근 보잉 737 MAX 사건을 생각해보면 생명에 필수적인 자동조종장치와 전산화된 비행제어 시스템이 분명히 존재하지만, 생각하지 못한 부분도 많다. 집에서 HVAC 시스템의 팬이 고장나서 약간의 연기가 나면 창을 열거나 바깥으로 나가 신선한 공기를 쐬십시오. 대서양 횡단 비행 중에 창문을 열고 밖으로 나가려고 시도한 적이 있습니까? 조리실의 전원 콘센트에서 음료수 카트 바퀴의 브레이크에 이르기까지 가장 기본적인 시스템조차도 항공기에서 생명에 치명적일 수 있습니다.
• 연락. 대부분의 개발자나 엔지니어는 경력의 어느 시점에서 이런 식으로 통신 시스템 프로젝트에서 작업합니다. 많은 사람들에게 통신은 처음에는 생명에 중요한 것처럼 보이지 않습니다. 결국, 문명은 전화와 인터넷 이전에 잘 버텼습니다. 통신 인프라가 파괴된 재해 지역에 배치된 사람으로서 실제로 어떤 일이 발생하는지 말씀드리겠습니다. 노인 거주자는 자녀에게 전화를 걸어 약국에서 처방전을 가져오도록 요청할 수 없습니다. 응급 구조원은 디스패처 또는 서로 통신할 수 없습니다. 그리고 가족과 연락이 되지 않는 사람들은 걱정이 되어 가족을 찾기 위해 극도로 위험한 상황에 처하게 됩니다. 통신 시스템은 절대적으로 생명에 매우 중요합니다.

기술에 대한 의존도가 높은 오늘날의 세계에서는 그다지 중요하지 않다고 생각했던 프로젝트가 결국 생명에 중요한 시스템의 중요한 구성 요소가 될 수 있습니다.

하지만 고장나지 않았다면 고치지 마세요

기술 시스템과 관련하여 "유산"이라는 단어를 들어 보거나 사용한 적이 있습니까? 오랜 전통과 혈통, 그리고 어려운 옛날을 떠올리게 하는 강한 단어입니다. 엔지니어링 세계에서 오랫동안 사용되어 왔으며 안정적으로 작동하는 것으로 입증된 설계를 나타내는 데 사용되며 종종 위험을 줄이는 데 바람직한 특성으로 간주됩니다. 실제로 위험 회피로 인해 업데이트되지 않은 구식 기술의 완곡어법이며 시스템 오류가 심각한 결과를 초래할 수 있는 산업에 만연해 있습니다.

전통적 소프트웨어 및 하드웨어에 대한 이러한 친화력 뒤에는 타당한 이유가 있습니다. 작동하는 것으로 알려져 있고 알려지지 않은 버그가 발생할 가능성이 거의 없으며 비용이 안정적이고 예측 가능합니다. 우주 비행 산업이 좋은 예입니다. 러시아 소유즈 우주선은 50년 넘게 우주 비행사를 우주로 발사했으며 그 기간 동안 약간의 수정만 가해 왔으며 안정적이고 안전하기 때문에 계속 사용하고 있습니다. 불행히도 이것은 현대적인 디자인에 비해 매우 비효율적이라는 것을 의미합니다. 소유즈는 유산 하드웨어를 사용하여 우주 비행사를 우주 정거장으로 비행시키는 데 NASA가 좌석당 8,100만 달러의 비용을 들이지만 SpaceX와 Boeing은 각각 5,800만 달러에 좌석을 제공할 것으로 예상됩니다. 그들의 현대적인 로켓 디자인을 사용합니다.

여전히 작동하는 오래된 시스템을 업그레이드하려는 사람은 거의 없습니다. 경영진은 위험을 원하지 않으며, 기술자는 가동 시간이 12년인 벽장에 있는 불가사의한 서버를 처리하는 것을 원하지 않으며, 클라이언트는 새로운 설계를 배워야 하는 것을 원하지 않습니다. 불행히도 위험 최소화와 비용 절감 사이에 전환점이 있습니다. 유산 디자인은 결국 고위험 환경에서도 업그레이드해야 합니다 .

이 문서의 나머지 부분에서는 응급 구조대, 군대 또는 항공기에서 사용하는 시스템과 같이 시스템이 생명에 중요한 경우 이를 수행하는 과정에서 보다 중요한 몇 가지 단계를 다룹니다.

황동 설득하기

내 경험상 가장 어려운 단계는 의사 결정권자와 이해 관계자에게 업그레이드가 필요하다는 확신을 주는 것입니다. 생명이 중요한 환경에서 작동하는 시스템은 종종 광범위한 법적 규제 및 조직 정책의 적용을 받으므로 위험을 감수하고 비용을 지출해야 할 뿐만 아니라 쉽게 여러 가지가 될 수 있는 작업에도 참여해야 함을 확신시켜야 합니다. 수년간의 관료적 테이프 커팅. 당신이 직면하게 될 가장 강력한 반대는 법무팀에서 나올 것입니다. 법무팀은 새로운 기술을 도입함으로써 조직을 열게 될 잠재적 책임 을 극도로 자세하게 설명할 것입니다. 그들의 말이 맞습니다. 책임은 중요한 문제 이며, 무언가가 파손되어 누군가가 다치거나 사망하는 경우 윤리적, 평판 및 재정적 부담이 클 수 있습니다.

Fortune 500대 기업 또는 지역 자원 봉사 소방서와 함께 일하든 관계없이 항상 같은 문제로 귀결됩니다. 바로 돈입니다. 기업은 그것을 잃는 것을 원하지 않으며 비영리 단체는 애초에 작업할 것이 많지 않습니다. 조직의 리더십이 생명에 중요한 시스템을 변경하는 위험을 감수하도록 설득하는 유일한 신뢰할 수 있는 방법은 확률적으로 손실보다 돈을 벌거나 절약할 가능성이 더 높거나 기술을 현대화하고 안전을 개선하여 책임을 줄입니다.

즉, 계산을 해야 합니다. 버그로 인해 다운타임이 연장되거나 향후 충돌이 발생할 가능성은 어느 정도입니까(귀하의 조직의 이전 배포 또는 다른 조직의 데이터를 기반으로 함)? 실패할 경우 예상되는 영향은 무엇이며 비용은 얼마입니까? 반대로 예상되는 성능 또는 안정성 향상은 무엇이며 그 가치는 무엇입니까? 앞서 나올 가능성이 높다는 것을 보여줄 수 있다면 청신호를 받을 가능성이 큽니다.

당신에 관한 것이 아닙니다

엔지니어가 자신과 비슷한 자격을 가진 사람들이 사용할 수 있는 것을 만들었다는 관용구인 "by Engineers, for Engineers"라는 문구에 익숙할 것입니다. 이것은 매우 흔한 일이며 1990년대 초 컴퓨터 사용성 연구의 부상을 촉발한 주요 요인 중 하나였습니다. 엔지니어로서 우리는 종종 일반 최종 사용자와 기술 시스템이 작동하는 방식에 대한 다른 멘탈 모델을 가지고 있어 최종 사용자가 시스템이 어떻게 작동하는지 이미 알고 있다는 가정 하에 시스템을 설계하는 경향이 있습니다. 기존 시스템에서는 오류가 발생하고 클라이언트가 만족하지 않습니다. 생명에 중요한 시스템에서는 사망으로 이어질 수 있습니다.

에어 프랑스 447편의 경우를 생각해 보십시오. 2009년 6월 1일, 에어버스 A330은 리우데자네이루에서 파리로 가는 도중 대서양을 건너고 있었습니다. 얼음 결정이 피토관을 막아서 공기 속도 측정에 불일치가 발생했습니다. 비행 컴퓨터는 잘못된 속도 데이터로 비행기 자체를 안정적으로 비행할 수 없다는 것을 인식하고 자동 조종 장치를 해제했습니다. 그런 다음 조종사가 컴퓨터가 일반적으로 허용하지 않는 기동을 수행할 수 있는 "확장 비행 범위" 모드로 전환되었습니다. 시스템을 구축한 엔지니어가 "자동 조종 장치가 스스로 해제되면 조종사가 추가 제어가 필요한 상황이 있기 때문일 것입니다!" 라고 생각하는 것을 상상할 수 있습니다. "

이것은 어떤 종류의 것이 자동 조종 장치를 해제할 수 있는지 이해하는 엔지니어를 위한 자연스러운 생각입니다. 조종사에게는 그렇지 않았습니다. 그들은 항공기가 모든 속도를 잃고 바다로 추락할 때까지 "STALL" 경고를 무시하고 가파른 상승을 강요했습니다. 228명의 승객과 승무원 전원이 사망했습니다. 그들의 행동에 대한 정확한 동기에 대해서는 여러 가지 아이디어가 있지만, 지배적인 이론은 조종사가 비행 컴퓨터가 항공기를 실속시키는 제어 입력을 방지할 것이라고 가정하고(정상 비행 범위에 해당) 컴퓨터의 결정을 이끄는 논리에 대한 엔지니어의 정신 모델을 공유하지 않았기 때문에 확장 엔벨로프 모드로 전환했습니다.

약간의 순환 경로가 있지만 이것은 우리를 제 요점으로 이끕니다. 특정 조건에서 사용자가 취하기를 원하는 작업은 사용자에게 자연스럽게 느껴지는 작업이어야 합니다 .

사용자는 특정 절차를 따르도록 지시받을 수 있지만 항상 옳은 일을 기억하거나 스트레스가 많은 상황에서 일어나는 일을 이해하지는 못합니다. 사용자가 본질적으로 해야 할 일을 하고 싶게 만드는 직관적인 방식으로 소프트웨어, 컨트롤 및 인터페이스를 설계하는 것은 귀하의 책임입니다.

이것이 의미하는 바는 최종 사용자가 설계 및 개발 프로세스의 모든 단일 단계에 참여하는 것이 절대적으로 중요하다는 것입니다. 사용자가 무엇을 할 것인지에 대해 가정할 수 없습니다. 모두 증거 기반이어야 합니다. 인터페이스를 디자인할 때 사용자에게 유도하는 사고 패턴을 파악하고 필요에 따라 조정하기 위한 연구를 수행해야 합니다. 새 시스템을 테스트할 때는 실제 조건에서 실제 환경의 실제 사용자와 함께 테스트해야 합니다. 불행히도 디자인을 변경할 때 이 단계를 다시 수행해야 합니다.

모든 복잡한 시스템은 고유하지만, 특히 보편적으로 적용되어야 하는 세 가지 설계 고려 사항을 언급하고 싶습니다.

• 컨트롤은 호출하는 작업을 나타내야 합니다. 다행히도 이것은 GUI 버튼에 대한 관련 아이콘 또는 물리적 컨트롤에 대한 관련 모양을 선택하는 형태로 일반적으로 볼 수 있는 매우 일반적입니다. "새 파일" 버튼은 빈 종이 아이콘을 사용하고 항공기의 랜딩 기어 레버에는 바퀴 모양의 손잡이가 있습니다. 그러나 안주하기 쉽습니다. "저장" 버튼에 대해 여전히 3.5" 플로피 디스크 아이콘이 표시되는 이유는 무엇입니까? 25세 미만의 사람이 플로피 디스크가 무엇인지 아는 사람이 있습니까? 대표라고 생각해서 계속 사용하고 있는데 사실 더 이상은 아니다. 컨트롤의 표현이 사용자에게 의미가 있는지 확인하려면 끊임없는 노력이 필요하지만 연속성과 균형을 맞추는 것도 필요하고 어렵습니다.
• 경고 시스템이 고장 나면 감지할 수 있어야 합니다. 깜박이는 빨간색 표시등과 같이 문제가 있을 때 활성화되는 경고등을 자주 사용합니다. 사용자의 관심을 끌기에는 좋은데 불이 꺼지면 어떻게 될까요? 아폴로 달 탐사선에 사용된 우주선에는 온갖 종류의 시스템에 대해 수십 개의 경고등이 있었지만 기존 방식으로 작동하지 않았습니다. 문제가 있을 때 불이 켜지지 않고 정상일 때 계속 켜져 있고 문제가 있을 때 꺼 졌습니다 . 이렇게 하면 불이 꺼진 경고등이 우주 비행사가 잠재적으로 치명적인 시스템 오류를 놓치는 일이 없도록 했습니다. 1960년대 이후로 전구의 신뢰성이 크게 향상되었기 때문에 이 디자인을 사용해야 한다고 말하는 것은 아니지만 계획의 일부가 얼마나 깊이 있어야 하는지에 대한 아이디어를 제공합니다. 시스템이 충돌한 적이 몇 번이나 있었지만 로깅 또는 알림이 제대로 작동하지 않아 이에 대해 알지 못했습니까?
• 모드 전환은 사용자에게 명확해야 합니다. Airbus A330이 사용자가 눈치채지 못하는 사이에 일반 제어 모드에서 고급 제어 모드로 전환하고 갑자기 기체가 사용자가 할 수 없다고 생각한 작업을 수행하면 어떻게 될까요? 자율 주행 자동차가 자동 조종 장치를 해제하여 예기치 않게 사용자가 완전히 제어할 수 있게 된다면 어떻게 될까요? 사용자의 행동을 즉시 변경해야 하는 모드나 기능의 주요 전환이 있지만 사용자가 방금 일어난 일을 파악하는 데 1~2분이 소요되면 어떻게 됩니까? 복잡한 시스템에서는 다양한 작동 모드가 필요할 수 있지만 적절한 통지, 설명 및 사용자와의 상호 작용 없이는 모드가 전환될 수 없습니다.

생명에 중요한 시스템을 공장에서 출고

업계 모범 사례에 따라 베타 단계는 생명에 중요한 새로운 시스템 배포에 매우 중요합니다. 새로운 기술의 테스트는 대부분의 버그와 사용성 문제를 수정하는 데 도움이 되었을 수 있지만 실제 환경에서 다른 시스템과 함께 사용해야 하는 경우 숨겨진 위험이 나타날 수 있습니다. 시스템 공학 분야에서는 이것을 "창출"이라고 합니다. 긴급 속성은 "응용 프로그램 구성 요소와 해당 환경 간의 상호 작용에서 비롯된 예기치 않은 동작" 이며 본질적으로 실험실 환경에서 감지하는 것이 본질적으로 불가능합니다. 최종 사용자의 대표 그룹을 초대하여 신중한 감독 하에 새 시스템을 시험해 보도록 하면 이러한 속성 중 많은 부분을 감지하고 본격적인 배포에서 나타날 수 있는 부정적인 결과에 대해 평가할 수 있습니다.

고객과의 아키텍처 논의에서 자주 발생하는 또 다른 주제는 단계적 출시입니다. 이것은 결국 모든 것이 교체될 때까지 기존 시스템의 요소를 새로운 요소로 점진적으로 교체하는 것과 한 번에 모든 것을 변경하는 것 사이의 선택입니다. 각각 장단점이 있습니다. 단계적 출시를 통해 사용자가 새로운 디자인에 점진적으로 적응할 수 있으므로 변경 사항이 관리 가능한 수준으로 증가하고 사용자가 압도당하지 않도록 합니다. 반면에 장기간에 걸쳐 프로세스를 끌어서 일정한 전환 상태를 초래할 수 있습니다. 즉각적인 롤아웃은 "반창고를 제거"하고 작업 속도를 높인다는 점에서 유리하지만 갑작스러운 급격한 변화는 사용자를 압도할 수 있습니다.

생명이 중요한 시스템의 경우 단계적 롤아웃이 일반적으로 프로덕션 환경의 개별 구성 요소에 대한 증분 평가를 허용하고 롤백이 필요한 경우 더 작은 복귀를 허용하기 때문에 더 안전하다는 것을 알았습니다. 그러나 이것은 사례별로 평가해야 할 사항입니다.

일탈의 정규화

자, 사용자 테스트는 직관적인 시스템을 설계하는 데 도움이 되었고, 베타 단계에서는 긴급한 문제를 식별했으며, 단계적 출시를 통해 사용자는 디자인에 익숙해졌고 모든 것이 원활하게 실행되고 있습니다. 끝났어, 그렇지? 불행히도.

시스템 문제는 필연적으로 발생하며 이를 해결할 방법이 없습니다. 사용자가 이러한 문제에 직면하면 기술 팀에 문제를 보고하는 대신 해결 방법을 개발하는 경우가 많습니다. 해결 방법은 베테랑부터 신인까지 "팁"으로 공유되는 표준 관행이 될 것입니다. 사회학자 Diane Vaughan은 이 현상을 설명하기 위해 "일탈의 정상화"라는 문구를 만들었습니다. 사용자는 일탈 행동에 너무 익숙해져서 그것이 실제로 일탈이라는 사실을 기억하지 못합니다.

고전적인 예는 우주 왕복선 챌린저(Space Shuttle Challenger)입니다. 고체 로켓 부스터의 구성 요소가 발사 중에 부식되는 것이 정기적으로 관찰되었으며, 로켓 구성 요소가 부식되는 것이 나쁜 것이라는 것을 모두가 알고 있었지만 너무 자주 발생하여 면제가 정기적으로 발행되었고 고려되었습니다. 정상. 1986년 1월 28일, 모두가 원래는 허용해서는 안 된다고 알고 있던 문제가 정상화되어 챌린저호가 폭발하고 7명의 우주인이 사망하는 문제가 발생했습니다.

생명에 중요한 시스템의 관리자로서 이러한 일이 발생하지 않도록 방지하는 것은 귀하에게 달려 있습니다. 사용자가 시스템과 상호 작용하는 방식을 연구합니다. 며칠 동안 그림자를 만들고 예기치 않은 해결 방법을 사용하고 있는지 확인하십시오. 정기적으로 설문 조사를 보내 제안된 변경 사항 및 개선 사항을 요청하십시오. 사용자가 귀하 없이 문제를 해결할 수 있는 방법을 찾기 전에 시스템을 개선하는 데 시간과 노력을 할애하십시오.

압박을 받는 성과를 위한 훈련

사용자가 스트레스, 아드레날린 급증 및 터널 비전으로 고통받을 때 생명에 중요한 시스템의 장애가 발생하는 경우가 많습니다. 에어프랑스 447기의 조종사들에게 일어난 일, 첫 번째 심정지 환자의 심장 모니터 작동 방법을 기억하지 못하는 구급대원, 사격 중에 라디오를 제대로 작동하지 못하는 군인들에게 일어난 일입니다.

이러한 위험 중 일부는 앞에서 설명한 직관적인 디자인을 사용하여 개선되지만 그것만으로는 충분하지 않습니다. 특히 스트레스가 높은 시나리오가 발생하지만 드물게 발생하는 환경에서는 시스템을 작동하는 방법뿐만 아니라 그러한 상황에서 명확하게 생각하는 방법을 사용자에게 교육하는 것이 중요합니다. 사용자가 장비 작동과 관련된 작업을 암기하면 학습한 작업이 더 이상 적절하지 않을 수 있으므로 예기치 않은 오류에 대처할 수 없습니다. 스트레스를 받는 상황에서 논리적이고 명확하게 생각하도록 훈련하면 변화하는 상황에 대처할 수 있고 문제가 발생했을 때 시스템이 살아 있도록 도울 수 있습니다.

결론

분명히 생명에 중요한 소프트웨어를 개발, 배포 및 유지 관리하는 것은 단일 기사에서 자세히 설명할 수 있는 것보다 훨씬 더 복잡합니다. 그러나 이러한 고려 영역은 그러한 프로젝트 작업에 대해 생각할 때 무엇을 기대해야 하는지에 대한 더 나은 아이디어를 제공하는 데 도움이 될 수 있습니다. 요약하자면:

• 모든 것이 원활하게 작동하더라도 혁신이 필요합니다.
• 경영진에게 위험을 감수할 가치가 있다고 확신시키기는 어렵지만 숫자는 거짓말을 하지 않습니다
• 최종 사용자는 프로세스의 모든 단계에 참여해야 합니다.
• 실제 조건에서 실제 환경에서 실제 사용자와 테스트 및 재 테스트
• 처음에 올바르게 이해했다고 가정하지 마십시오. 작동하더라도 사용자가 알려주지 않는 감지되지 않은 문제가 있을 수 있습니다.
• 시스템을 사용하는 방법뿐만 아니라 명확하게 생각하고 스트레스를 받는 상황에서 적응하는 방법에 대해 사용자를 교육하십시오.

끝으로, 복잡한 안전이 중요한 시스템에서는 아무리 많은 계획, 테스트 및 유지 관리를 수행하더라도 어느 시점에서 문제가 발생한다는 점을 말씀드리고 싶습니다. 이러한 시스템이 생명에 매우 중요한 경우 고장으로 인해 생명이나 팔다리가 손실될 수 있습니다.

자신이 책임져야 할 일에 그런 비극이 일어난다면, 양심에 짓눌린 무거운 짐이 될 것이고, 조금만 더 주의를 기울이거나 더 열심히 했다면 막을 수 있었을 것이라고 생각할 것입니다. 그게 사실일 수도 있고 아닐 수도 있지만, 가능한 모든 상황을 예측하는 것은 불가능합니다.

세심하게 일하고, 자만하지 마십시오. 그러면 세상을 더 나은 곳으로 만들 수 있습니다.