| 스피커 |
성적 증명서 |
| 브래드 폴크스 |
"하지만 이제 뭘 해야 할까요? JMP에서 신뢰성 모델을 사용하여 이벤트 예측하기"라는 제 강연에 참석해 주셔서 감사합니다. |
| |
신뢰성 모델을 구축하면 실제로 어떻게 활용해야 하는지 자주 묻는 질문들이 있습니다. 사람들은 종종 신뢰성 모델을 사용하여 실제 사건이 언제 발생할지 예측할 수 있다는 사실을 잊곤 합니다. |
| |
그리고 첫 번째 이벤트뿐만 아니라, 시간이 지남에 따라 해당 제품이 접하게 될 두 번째, 세 번째 또는 네 번째 이벤트도 있을 수 있습니다. |
| |
제 소개를 간략히 드리겠습니다. 저는 브래드 폴크스입니다. Optimal Analytics의 엔지니어링 책임자로, 기업들과 협력하여 데이터를 이해하고, 장애물을 파악하고, 더욱 효율적으로 운영할 수 있도록 지원합니다. |
| |
그 전에는 신뢰성 엔지니어링 분야에서 약 9년간 일했는데, 부품 신뢰성을 이해하고 시간이 지남에 따라 부품이 실제로 고장나는 시기를 알아내는 방법을 연구했습니다. |
| |
저는 JMP를 8년 정도 썼는데, JMP 10 버전이었던 것 같습니다. 꽤 오래 전이라 어떤 버전을 사용했는지 기억이 나지 않네요. 그때는 제가 JMP를 사용했었습니다. |
| |
제가 가장 좋아하는 JMP 도구에서 수명 분포를 자주 사용하는 이유는 신뢰성 모델링이 바로 거기에 있기 때문입니다. 적합 모델과 JSL을 아주 자주 사용합니다. |
| |
스크립팅은 여러분에게 완전히 새로운 도구와 장난감을 열어줄 수 있습니다. 그렇다면 오늘 이 내용을 소개하는 이유는 무엇일까요? |
| |
왜냐하면, 대부분의 경우 이 질문은 모델을 만드는 마지막에 떠오르지만, 그때까지는 실제로 생각하지 못했기 때문입니다. |
| |
모델을 완성하고 나서 온갖 가능성을 다 고려하고 나서도 다음에 무엇을 해야 할지 막막할 때가 있습니다. 모델을 완성한 후 계속해서 진행할 수 있는 한 가지 방법을 알려드리겠습니다. |
| |
오늘 우리가 이야기하는 사건 예측은, 모델을 만들 때 흔히 이런 종류의 플롯을 보셨을 겁니다. 각자의 시간을 갖게 되죠. |
| |
그리고 아마도 이것들은 하드웨어나 제품 수명 주기일 겁니다. 예를 들어 믹서기나, 아니면 오래가지 못하는 어떤 종류의 주방 가전제품이나 소형 주방 가전제품이라고 해 봅시다. |
| |
엄청나게 오랜 시간이 걸립니다. 그래서 이 중 일부는 아주 일찍 실패할 것이고, 일부는 아주 늦게 실패할 것입니다. |
| |
하지만 결국에는 이런 일들이 일어날 때 실패할 확률이 생깁니다. 그래서 "좋아요, 실패의 약 90%는 4년 안에 일어날 겁니다."라고 말할 수도 있겠죠. |
| |
음, 좋네요. 첫 번째 고장을 어느 정도 파악하고 현장에서 부품 고장 가능성을 예측하는 데는 도움이 되지만, 실제로 이런 제품을 사거나 사용해야 하는 사람에게는 큰 도움이 되지 않습니다. |
| |
실제로 이 제품을 사용하는 고객은 얼마나 오래 사용할 수 있을지는 신경 쓰지 않습니다. 일정 기간 동안 얼마나 많이 사야 할지 알고 싶어 하지 않을 수도 있습니다. |
| |
아마도 전체 수명 주기에 따라 달라질 수 있습니다. 10년만 보고 싶어 하는데, 10년 후에 이 중 몇 개를 사야 살아남을 수 있을까요? |
| |
그래서 사건 예측이 등장하게 되는 겁니다. 사건 예측이란 실제로 분포를 가져와서 뒤집어서 여전히 시간 분포를 유지하는 것입니다. |
| |
여기 있는 사건들이 발생하기까지의 시간과 사건의 확률은 얼마입니까? 그리고 이제 |
| |
이러한 사건들이 얼마나 자주 발생하는지 살펴보세요. 첫 번째 사건은 8년 반쯤에 발생하고, 두 번째 사건은 9년 반에 발생하고, |
| |
세 번째 이벤트... 하지만 이건 모두 하나의 고객입니다. 그러니까 이 모든 게 하나의 고객, 하나의 사용 사례이고, 그래서 그들에게는, 아시다시피, 실패까지의 시간이죠. |
| |
여기 있는 모든 부분들을 살펴보고, 모든 간격과 교체를 살펴보겠습니다. 그래서 여기, |
| |
고객이 실제로 이 제품을 보는 데 20년 이상이 걸립니다. 그래서 고객은 "20년 동안, 또는 그 20년을 버티려면 최소 세 개의 부품이 필요할 겁니다."라고 묻겠죠. |
| |
따라서 이러한 무작위 선택과 시뮬레이션을 활용하면 이러한 부품을 얼마나 자주 교체해야 하는지, 그리고 고객이 얼마나 자주 제품을 구매해야 하는지 파악할 수 있습니다. |
| |
그럼, 이게 어떻게 실용적일까요? 좋아요, 결국 대체품에 관한 이야기로 귀결되죠. |
| |
그리고 교체란, 얼마나 자주 새 부품이나 새것과 같은 부품을 장착하느냐는 것입니다. |
| |
수리 가능한 시스템과 수리 불가능한 시스템이 있습니다. 수리 가능한 시스템이란 바로 |
| |
다시 달릴 수 있다는 점, 그리고 새 차만큼 좋지 않을 수도 있다는 점이죠. 타이어에 구멍이 났다고 가정해 봅시다. 새는 곳을 막고 계속 달리면 됩니다. |
| |
수리는 끝났어요. 하지만 타이어를 새것처럼 수리해서 다시는 고장 나지 않게 할 수 있다면 어떨까요? |
| |
타이어의 경우에는 그다지 실용적이지 않을 수 있지만, 다른 것의 경우에는 부품을 교체해야 할 수도 있고, 부품의 일부를 잘라내어 고장난 부품이나 그 부품만 교체해야 할 수도 있습니다. |
| |
부품을 새것처럼 만들면 이 시스템은 수리가 불가능해질 수 있습니다. 따라서 수리를 했더라도 새것처럼 만들려면 |
| |
조금 바뀌긴 하죠. 아시다시피, 이건 엄청난 경고죠. 새것만큼 좋다는 게 무엇을 의미하는지 많은 걸 고려해야 하지만, 제 생각엔 아주 자주, 어떤 부분은... 혹은 사람들이 어떤 부분을 다루는지... |
| |
그들은 수리를 해 왔고, 새것처럼 잘 수리합니다. 그러면서 "이건 수리 가능한 시스템인데, 신뢰성 측면에서는 그렇지 않다"고 생각합니다. 좋아요, 그럼 저는 잠깐 연설에서 물러나겠습니다. |
| |
교체로 돌아가서, 우리가 단일 시스템을 살펴볼 때, |
| |
당신은 여기 무언가를 보고, "알았어, 알았어"라고 말할 수도 있습니다. |
| |
하나의 단일 시스템에 대해 |
| |
부품 고장 빈도는 얼마나 되나요? 고객 한 명만 놓고 보면, 얼마나 자주 부품을 구매하나요? 첫 번째 부품은 여기서 4년 동안 버텼습니다. |
| |
그러고 나서 두 번째 차를 사야 했어요. 그 차는 1.3년밖에 못 탔고, 그다음 세 번째 차를 사야 했는데, 이번에는 대박이 나서 8년이나 탔어요. |
| |
결국 12년 동안 부품 세 개를 사야 했지만, 차이가 꽤 큽니다. 온갖 제품, 일부 휴대폰, |
| |
다른 가정용 제품들도 마찬가지입니다. 어떤 제품은 일찍 고장 나고, 어떤 제품은 늦게 고장 납니다. |
| |
친구들과 이야기하며 "이봐, 나... 이 끔찍한 휴대폰을 가지고 있어. 이렇게 일찍 고장 났다니 믿기지 않아."라고 말할지도 몰라요. 그리고 친구들은 10년 동안 써 온 그 휴대폰에 대해 이야기할 거예요. 10년은 아니겠지만요. |
| |
시간이 꽤 걸릴 수도 있습니다. 결국 이 시스템 하나, 이 고객 하나 때문에 부품을 세 번이나 교체해야 했습니다. |
| |
이제 여러 시스템을 살펴보면 시간이 지남에 따라 이러한 일이 얼마나 자주 발생하는지 파악할 수 있습니다. |
| |
한 고객이 첫 번째 시스템을 사용했고, 두 번째 고객이 그 기간 동안 5번이나 6번이나 교체를 했을 수도 있습니다. 거의 같은 기간 동안 말이죠. |
| |
그러니 첫 번째 시스템을 살펴보면, 적어도 4년차까지는 실패가 없을 거라고 말할 수 있을 겁니다. |
| |
하지만 두 번째 시스템을 살펴보면, 1년차에 장애가 발생했습니다. 따라서 1년차나 2년차에 예상되는 평균 장애 발생 횟수나 평균적인 이벤트 발생 건수를 파악하려고 한다면, |
| |
첫 번째 시스템은 우리에게 많은 것을 알려주지 않습니다. 그래서 만약 데이터가 없고... 모델에 분포가 있는데, 와이불의 베타와 에타 같은 것이 있다면, |
| |
시뮬레이션을 사용하면 일부 고객이 1년, 2년, 3년차에 얼마나 자주 이벤트를 기대하는지 파악할 수 있으며, 실제 데이터보다 훨씬 더 멀리까지 확장할 수 있습니다. |
| |
그렇게 하면 여러 시스템을 살펴보고 시뮬레이션을 살펴보면 얼마나 자주 발생하는지에 대한 추세를 이해하고 확인할 수 있습니다. |
| |
이 부품들은 매년 교체될 예정입니다. 따라서 여기 있는 데이터는 7년간의 이벤트 기간만을 기반으로 작성되었을 수 있지만, |
| |
달력 시간이나 고객 시간 동안 일종의 급증이 있을 것이고, 그 후 일정 수준으로 평준화될 것입니다. 이제 |
| |
시뮬레이션을 하면 약간의 바운싱 현상이 나타나는데, 여기 보이는 것이 바로 그것입니다. 이 문제에 대한 닫힌 형태의 해를 구하면 멋진 직선을 얻을 수 있겠지만, |
| |
시뮬레이션을 통해 약간의 변화가 발생합니다. 여기서 보시는 것이 바로 그것입니다. 선을 그어 보면 평균적으로 |
| |
사람들은 매년 이 중 3분의 1 정도를 교체할 것으로 예상할 수 있습니다. 그러니까 3년 후에는, 작동이 시작되면 교체품을 받게 될 겁니다. 처음에는 몇 개 정도만 교체하고 그 후에는 어느 정도 안정을 찾게 됩니다. |
| |
그러면 제가 말하는 바가 무엇인지 예를 들어 보겠습니다. |
| |
여기 데이터 테이블이 있고, 여기 모델이 있습니다. 이 모델은 무작위 와이불 모델입니다. JMP에서 사용할 수 있는 다양한 함수에 익숙하지 않으시다면, |
| |
무작위 와이블, 와이블 분위수, 와이블 분포, 와이블 밀도를 사용할 수 있습니다. 이러한 함수는 모두 다양한 분포에 적용할 수 있습니다. |
| |
이 경우, 특정 분포에서 무작위로 점 집합을 선택합니다. 제 분포의 베타는 1.2이고 에타는 3입니다. |
| |
그래서, 여기서 이러한 무작위적인...무작위적인 이벤트를 선택함으로써, |
| |
이것들은 모두 개별적인 사건이며, 결국 모델에 반영되는 내용입니다. 부품 고장을 기반으로 모델을 구축한다면, 일반적으로 모델에 반영되는 날짜는 다음과 같습니다. 하지만 이것이 실제로 고객에게 어떤 영향을 미치는지는 간과됩니다. 시간이 지남에 따라 |
| |
고객은 20년, 30년, 40년 후에 이 중 몇 개를 교체해야 할지 알고 싶어할 수도 있습니다. |
| |
여기서 전체 시스템 이벤트 시간을 살펴봐야 합니다. 이는 개별 시간의 누적 합계이므로, 8.3이 첫 번째, 1.2가 두 번째 등입니다. |
| |
그래서 두 번째 시스템으로 가면 1.8, 3.9, 5.9가 나오는데, 이는 개별 시간의 누적된 숫자일 뿐입니다. |
| |
여기서 명심해야 할 점은 이 모든 것의 평균을 알아내려고 할 때, |
| |
시스템 번호를 살펴보면서 실제로 이 사건이 발생한 연도를 보면 운영 2년차에 1.8년이 발생했다는 것을 알 수 있습니다. |
| |
그리고 여기서 명심해야 할 중요한 구별은, 적절한 해에 실패를 식별해야 하기 때문입니다. |
| |
그러니까 0.6인데... 만약 그게 첫 번째라면 1년차일 텐데, 실제로는 1년씩 증가하는 거죠... 시스템 시간... 시스템 연도를 여기서 1씩 증가시키는 겁니다. |
| |
자, 이렇게 하면 "좋아, 이제 모든 걸 다 갖추었으니 이벤트 개수를 세고 이 시스템과 연도를 살펴보고 간단한 분석을 해 보자"라고 생각할 수도 있습니다. JMP에는 이 모든 작업을 대신해 주는 훌륭한 도구가 있습니다. |
| |
그래서 |
| |
JMP에는 수리 가능 시스템 시뮬레이션이라는 도구가 있습니다. |
| |
그리고 이 도구는, |
| |
알아요...JMP 13, 어쩌면 14에 나왔던 것 같아요. 몇 년 전부터 있었죠. |
| |
이것이 마땅히 받아야 할 홍보 효과를 거두지 못하는 것 같아요. 많은 사람이 이 기능을 높이 평가하지 않는 엄청나게 강력한 도구이기 때문이죠. |
| |
그러니까, 그러니까, 여기 시스템을 보고 계신 거예요. 그리고 어쩌면, 지금 당장은 두 부분이 있는데, 어쩌면 제 시스템은 실제로 |
| |
일곱 개나 여덟 개의 부품, 아니면 기어박스 전체, 펌프 같은 거요. 그리고 이 모든 부품들이 함께 작동해서, 그중 하나라도 고장 나면 |
| |
아시다시피, 전체 시스템이 실패하는 상황이죠. 그래서 이벤트가 무엇인지, 이벤트 시간이 어떻게 되는지 이해하고 싶어 합니다. 따라서 각 이벤트에 와이불(Weibull)이나 모델이 무엇인지 설명하면 됩니다. 여기 베타는 1.2이고 알파는 15입니다. |
| |
그것은 연도 단위이고, 내가 원한다면 다른 분포를 선택할 수도 있습니다. |
| |
그러면 이벤트가 발생하면 어떻게 될지 말할 수 있습니다. 예를 들어 블록이... 블록에 장애가 발생했는데, 실제로 장애가 발생하면 어떻게 될까요? |
| |
결국 새 제품으로 교체해야 하니, 부품만 교체하고 싶습니다. 여러 가지 방법이 있는데, 간단한 수리 정도만 할 수도 있겠지만, "새 부품으로 교체하고 싶다"라고 말씀드렸으니, 새 제품이나 다름없는 새 모델이 될 겁니다. |
| |
그리고 다운타임을 포함할 수 있습니다. 수리하는 데 얼마나 걸렸나요? 평균 수리 시간은 얼마였나요? 상수 값으로 설정할 수 있습니다. |
| |
아니면... 즉시라고 할 수도 있고, 시간이 얼마나 걸리든 상관없다고 할 수도 있고, 선택할 수 있는 목록을 제공할 수도 있습니다. 여기에 몇 가지 배포 방식을 지정할 수도 있습니다. |
| |
이런 도구들을 사용해서... 이제 아주 간단한 시스템을 구축했습니다. 제가 알고 있는 분포를 사용하는 부분이 하나 있고, 알려진 분포를 사용하는 부분이 두 개 있습니다. |
| |
두 가지 중 하나라도 실패하면 교체 시기가 정해지므로 두 번째 것에는 선택권이 있습니다. |
| |
보시다시피, 여기에 입력하셨죠? 이제 선택 항목들은 시뮬레이션과 동일한 시간 단위에 있어야 합니다. |
| |
그래서 시뮬레이션을 연 단위로 선택했습니다. 이건 연 단위라서, 뭔가를 준비하는 데 걸리는 시간이 한 시간, 두 시간, 어쩌면 하루 정도일 수도 있습니다. 하지만 이걸 연 단위로 계산하면 숫자가 정말 작아지죠. 그래서 여기 보이는 게 바로 그겁니다. |
| |
여기서 모든 옵션을 다루지는 않겠습니다. 보시다시피, 대기, N 중 K로 할 수 있는 다른 많은 작업들이 있는데, 그중 상당수는 더 복잡한 분석을 위한 것입니다. |
| |
좋습니다. 분석을 실행해 보겠습니다. 여기에 나열된 20년 동안 시뮬레이션을 실행하고, 시뮬레이션 횟수는 100회로 설정했습니다. 이보다 더 많은 횟수가 필요할 수도 있지만, 데모 목적으로 100으로 설정하고 시드를 1234로 설정하겠습니다. |
| |
그러면 여기서 굉장히 큰 출력을 얻게 되는데, 초기 출력은 항상 숫자라고 불리며, 이는 매우 유용합니다. |
| |
하지만 이걸 보고 "이걸 어떻게 해야 하지?"라고 생각하실 수도 있습니다. 그리고 여기로 와서 이 분석을 실행해 보세요. |
| |
구성 요소별 총 가동 중지 시간을 확인해 보는 게 어떨까요? 즉, 각 구성 요소에 발생할 수 있는 가동 중지 시간의 분포를 알 수 있다는 뜻입니다. |
| |
하지만 실제로 20년이 넘으면 이 부품을 몇 번 교체해야 할지에 대한 질문에는 답이 나오지 않습니다. |
| |
그래서 제가 대본을 썼고, 여러분이 이 일기를 다운로드하면 거기에는 모든 대본이 들어 있을 거예요. |
| |
저는 이것을 버튼으로 설정했지만, 실제 스크립트는 여러분이 참고할 수 있도록 바로 아래에 있습니다. 원하시면 사용하세요. |
| |
그래서 그냥 버튼을 클릭하면 여러 가지 일이 일어날 겁니다. 이제 들어가서 이러한 이벤트가 매년 얼마나 자주 발생할 것으로 예상되는지 계산해 봤습니다. 시스템 관점에서 보면, |
| |
실패 사건들을 부분집합으로 나누고 연도 값을 설정했습니다. 연도 값은 반올림해서 3.8년은 4가 된다는 걸 기억하실 겁니다. |
| |
이건 달력 시간을 보는 거고, 이건 우리가 사용하는 시스템 시간을 보는 겁니다. 개별 시간은 보지 않습니다. 그러니까, 첫 번째 행에서 두 번째 행까지의 시간 간격은 약 1.8년 정도입니다. |
| |
하지만 우리가 시스템을 살펴보면 실제로는 5.69를 세고 있는 셈입니다. |
| |
이제 이걸 바꾸고 싶습니다... 이 모든 값을 유용한 무언가로 바꾸고 싶습니다. |
| |
하지만 기억해야 할 중요한 점은... 매년 평균적인 사건 발생 건수를 구할 때는 사건이 발생하지 않은 해들도 살펴봐야 한다는 것입니다. 따라서 이 첫 번째 시뮬레이션에서 첫 번째 사건은 4년차에 발생했고, |
| |
하지만 1, 2, 3에는 0이 필요하고, 제 스크립트는 바로 그걸 담당합니다. 제 스크립트는 집합에 들어갑니다. |
| |
제가 살펴보고 싶은 패턴입니다. 1부를 살펴보겠습니다. 연도 값과 시뮬레이션 ID를 확인한 다음, 실제로 사건이 발생한 시점을 살펴보겠습니다. 여기서 1부의 첫 번째 사건이 10년차에 발생한 것을 확인할 수 있습니다. |
| |
그래서 여기에 추가되면 분석도 업데이트됩니다. 2부로 스크롤하면... |
| |
시뮬레이션 1의 두 번째 부분으로 스크롤하면, |
| |
...아무런 이벤트도 없습니다. |
| |
시뮬레이션 1의 첫 번째 이벤트는 ...까지 일어나지 않습니다. |
| |
4학년까지요. 그러니까 4학년까지 스크롤을 내리면 |
| |
두 번째 부분에서는 시뮬레이션 1에서 하나의 사건이 발생했음을 보여드리겠습니다. 즉, 이 사건이 발생할 수 있는 모든 연도의 조합에 대해 이러한 사건들을 정렬하는 것입니다. |
| |
글쎄요, 그 수준의 정보를 가지고 있으니, 이제 모든 시뮬레이션에 걸쳐 4,000개의 기록이 있는 걸 보셨죠. 이제 그게 연도, 시뮬레이션, 부품의 가능한 모든 변형일 뿐이에요. |
| |
하지만 사실 저는 이것들을 평균화하고 싶습니다. 그래서 평균을 내고, 시뮬레이션 횟수, 즉 행 수, 연도 값, 그리고 해당 부분을 살펴보고 싶습니다. 40행으로 줄이면 훨씬 관리하기 쉽고 이해하기도 훨씬 쉬워집니다. |
| |
두 번째 부분에서 보시는 건 처음에 살짝 솟아오르다가 어느 정도 수평을 이루는 거예요. 그리고 |
| |
시뮬레이션이기 때문에 100개의 이벤트만 실행했기 때문에 변동이 있지만... 100개의 시뮬레이션이더라도 우리는 볼 수 있는 대체품에 대한 안정적인 상태를 가지고 있습니다. |
| |
하지만 누적적인 관점에서 살펴보면, 이는 고객이 10년 후에 얼마나 많은 부품을 교체해야 할지 예측할 수 있는 지표입니다. 두 번째 부분에서는, |
| |
고객이 첫 번째 제품을 언제 교체해야 하는지 알고 싶어 한다고 가정해 봅시다. 첫 번째 제품은 무엇일까요? 첫 번째 제품은 무엇일까요? |
| |
4학년에서 5학년 사이, 4학년 직후에 일어날 거예요. 그리고 두 번째는 바로... 7학년쯤에 일어날 거예요. |
| |
세 번째 문제는 10년쯤에 발생합니다. 보시다시피 처음에는 고장이 많지 않지만 꾸준히 오르다 보면 3년마다 부품을 교체해야 합니다. |
| |
이는 고객, 사업 계획, 심지어 공급망 관리에도 매우 도움이 될 수 있습니다. 이런 일을 시도하고 싶다면 말이죠. |
| |
따라서 수리 가능 시스템 시뮬레이션에서 이 이벤트 예측을 활용하면 고장 발생 확률과 발생 시점뿐만 아니라 부품 수에 대한 아이디어나 이해를 제공하는 간편하고 빠른 방법입니다. |
| |
오늘 제가 이야기하고 싶은 또 다른 사항은 수리 가능한 시스템 시뮬레이션을 조금 더 쉽게 만드는 방법입니다. |
| |
그래서 어려울 수도 있습니다. 새로운 도구이기 때문에 작업하는 모든 것을 다 알지 못할 수도 있지만, |
| |
만약 당신이 템플릿으로 시작하고, 표로 시작한다면, 수리 가능한 시스템 시뮬레이션을 만드는 것이 훨씬 쉬워질 수 있습니다. |
| |
결국 모델을 구축하려면 약 13개의 데이터가 필요합니다. 이 중 대부분은 생각지도 못한 백그라운드에서 진행되지만, 이 데이터들을 표와 템플릿으로 정리하면 |
| |
이렇게 다양한 열이 있는데... 13개라고 하셨는데, 사실 더 적게 필요해요. 여기서 할 수 있는 몇 가지 멋진 기능들을 처리하기 위해 몇 가지 수정을 했습니다. |
| |
하지만 실제로는 분포, 모델 유형, 매개변수, 시간 단위 등이 있습니다. 이러한 모든 사항은 JMP에 기본값으로 설정되어 사용자가 변경할 수 있거나 |
| |
추가할 수 있는 것들이죠. 각 블록에 대해, 블록이 실패하면 무엇을 새 블록으로 교체할 것인지, 그리고 이벤트 이름과 프로세스를 다르게 연결하고 조정할 수 있습니다. |
| |
제 세상에서는 행동 변화가 자주 일어납니다. 그리고 처음 몇 년 동안은 이게 소득 대체율이고, 그다음 몇 년 동안은 이게 소득 대체율이라는 걸 이해하고 싶을 수도 있습니다. |
| |
아니면 활용하고 싶은 경쟁적인 실패 모드가 있을 수도 있습니다. 제가 여기서 보여드릴 내용은 그런 실패 모드를 많이 처리할 수 있습니다. |
| |
실례합니다. 이건 결코 완벽하지 않습니다. |
| |
확실히 귀하의 사용 사례에 맞게 조정해야 하지만 결국 템플릿으로 시작하는 것은 개발 속도를 높이는 놀라운 방법입니다. |
| |
조정이 가능하도록... 즉석에서 작은 조정을 할 수 있도록 말이죠. 예를 들어, 여기에 간단한 스크립트가 있는데, 이 스크립트를 클릭하면 수리 가능한 시스템 시뮬레이션이 자동으로 생성됩니다. |
| |
그리고 여기를 보면, 베타 1.86 또는 826, 알파 153의 첫 번째 부분이 있습니다. |
| |
그리고 실제로 이 테이블을 가져와서 수리 가능한 시스템 시뮬레이션으로 바꾸는 것입니다. |
| |
훨씬 더 복잡한 문제입니다. 그럼 이쯤에서 마무리하겠습니다. |
| |
그래서 여기 14개의 부분이 있습니다. 원하면 이 배포판을 변경할 수 있습니다. |
| |
하지만 여기서 살펴보고 싶은 다른 유형의 이벤트가 있습니다. 배포를 다음과 같이 나누고 싶습니다. |
| |
일정 시간이 지나면 형태가 바뀌거나 변합니다. 제품 출시나 전체 함대에 적용되는 제품 업그레이드를 모델링하려는 것일 수도 있고, 경쟁적인 실패 모드가 있을 수도 있는데, 그걸 고려하고 싶은 것일 수도 있습니다. |
| |
그러니까, 스크립트에 이 템플릿을 사용하면 이 모든 작업을 아주 간단하게 처리할 수 있습니다. 얼마나 빠른지 보셨죠? 1초 정도면 충분하죠. |
| |
이 모델을 생성하려면 어떻게 해야 하나요? 이제 이 모델을 또 하나 만들고 싶다면, 어쩌면 이걸 |
| |
정상 로그. |
| |
나는 바로 여기서 그것을 할 수 있고, 그 다음에 |
| |
내 대본을 읽어봐 |
| |
그리고 |
| |
다시 실행해 보세요. 그러면 또 다른 모델이 나오는데, (뭐였더라? 5부.) |
| |
5번째 부분은 이제 로그 정규화입니다. 다양한 반복과 모델을 시도해 보는 것이 정말 쉽고, 매번 새로운 모델을 생성합니다. |
| |
다이어그램에 표라고 라벨을 지정하세요. 이 템플릿을 사용하면 이벤트 예측을 분석하고 이해하는 데 매우 편리합니다. 여기에 내장된 스크립트를 사용하면 시간 경과에 따른 이벤트 예측을 분석하고 이해하는 데 도움이 됩니다. |
