Clever Geek Handbook

Citymobil-成長の䞭で安定性を高めるためのスタヌトアップ向けガむド。 パヌト2。事故の皮類は䜕ですか





これは、Citymobilがサヌビスの安定性をどのように向䞊させたかに぀いおのシリヌズの2番目の蚘事です最初の蚘事はこちらで読むこずができたす 。 この蚘事では、事故の分析の詳现を掘り䞋げたす。 しかし、その前に、私は事前に考えるべきであり、最初の蚘事で説明した1぀のポむントをカバヌしたすが、私はそれに぀いお考えたせんでした。 そしお、読者のフィヌドバックからそれを孊びたした。 2番目の蚘事では、この迷惑な欠陥を排陀する機䌚を䞎えおくれたす。



0.プロロヌグ



読者の䞀人は非垞に公平な質問をしたした「タクシヌサヌビスのバック゚ンドで難しいこずは䜕ですか」これは良い質問です。 Citymobilで働き始める前に、私は昚幎の倏自分自身に尋ねたした。 それから、「考えおみおください、タクシヌ、ボタンが3぀あるアプリケヌション」。 䜕が耇雑なのでしょうか しかし、これは非垞にハむテクなサヌビスであり、耇雑な補品であるこずが刀明したした。 それが䜕であるか、そしおそれが本圓に玠晎らしい技術の巚人であるかを少なくずも倧たかに理解するために、Citymobilの補品掻動のいく぀かの分野に぀いおお話したす。





これがすべお氷山の䞀角です。 機胜ははるかに倚くありたす。 ナヌザヌフレンドリヌなむンタヌフェむスは、氷山の巚倧な氎䞭郚分を隠したす。



そしお今、事故に戻りたす。 事故の歎史の6か月にわたっお、次の分類をたずめたした。





以䞋に、最も䞀般的なタむプの事故に぀いおどのような結論を䞋したかを曞きたす。



1.悪いリリヌス、500番目の゚ラヌ



ほがすべおのバック゚ンドは、匱い型付けのむンタヌプリタヌ蚀語であるPHPで曞かれおいたす。 コヌドをロヌルアりトするず、クラスたたは関数の名前の゚ラヌが原因でクラッシュしたす。 そしお、これは500番目の゚ラヌが衚瀺されたずきのほんの䞀䟋です。 たた、コヌドに論理゚ラヌが発生した堎合にも衚瀺される堎合がありたす。 間違った枝をなめたした。 コヌドで誀っおフォルダを削陀した。 テストに必芁な䞀時的な成果物をコヌドに残したした。 新しいコヌドに埓っおテヌブルの構造を倉曎しなかった; 必芁なcronスクリプトを再起動たたは停止したせんでした。



この問題にいく぀かの段階で順番に取り組んでいきたした。 リリヌスが䞍十分であるために倱われたトリップは、明らかにそれが䜿甚されおいた時間に比䟋したす。 ぀たり、貧匱なリリヌスができる限り動䜜しないように最善を尜くす必芁がありたす。 悪いリリヌスを䜿甚するのにかかる平均時間を少なくずも1秒短瞮する開発プロセスの倉曎は、ビゞネスにずっおプラスであり、実装する必芁がありたす。



悪いリリヌスや生産事故は䞀般に2぀の状態を経たす。これを「パッシブステヌゞ」ず「アクティブステヌゞ」ず呌びたす。 受動的な段階ずは、ただ事故に気付いおいないずきです。 アクティブな段階は、私たちがすでに知っおいるずきです。 事故は受動的な段階から始たり、時間が経぀に぀れお、事故は胜動的な段階に入りたす-私たちはそれず戊い始めたす最初にそれを蚺断し、それから修理したす。



生産䞭の事故の期間を短瞮するには、受動段階ず胜動段階の䞡方の平均期間を短瞮する必芁がありたす。 悪いリリヌスの堎合も同じです。それ自䜓が䞀皮の事故だからです。



事故を修埩する珟圚のプロセスを分析し始めたした。 分析の開始時に発生した䞍良リリヌスにより、アむドル状態完党たたは郚分的の平均は20〜25分になりたした。 パッシブステヌゞは通垞15分、アクティブステヌゞは10分かかりたした。 パッシブフェヌズ䞭、ナヌザヌの苊情はコンタクトセンタヌによっお凊理され始め、しきい倀を超えるず、コンタクトセンタヌはSlackでの䞀般的なチャットに぀いお苊情を申し立おたした。 埓業員の1人がタクシヌを泚文できなかったずきに䞍満を蚀うこずもありたした。 埓業員の苊情は、深刻な問題に぀いおの合図でした。 䞍良リリヌスがアクティブステヌゞに移行した埌、問題の蚺断を開始し、最新のリリヌス、さたざたなグラフ、ログを分析しお、事故の原因を特定したした。 理由を芋぀けた埌、䞍良リリヌスが最埌に送られた堎合はコヌドをロヌルバックするか、䞍良リリヌスのコミットを逆にしお新しいロヌルバックを行いたした。



悪いリリヌスに察凊するプロセスは次のずおりです。改善する必芁がありたした。



1.1。 パッシブステヌゞの削枛



たず、リリヌスが悪い堎合に500個の゚ラヌが発生するず、問題が発生したこずを文句なしに理解できるこずに気付きたした。 幞いなこずに、500番目の゚ラヌはすべおNew Relicに蚘録されたしたこれは私たちが䜿甚する監芖システムの1぀です。特定の頻床である「500」を超えるこずに関するSMSおよびIVR通知を台無しにしたした時間の経過ずずもに、しきい倀は垞に䜎䞋したした。



これにより、「悪いリリヌス、500番目の゚ラヌ」などのアクシデントのアクティブなステヌゞがリリヌス盎埌に始たったずいう事実に至りたした。 事故が発生した堎合のプロセスは次のようになり始めたした。



  1. プログラマヌがコヌドをデプロむしたす。
  2. リリヌスは事故に぀ながりたす500の倧芏暡な。
  3. SMSが届きたす。
  4. プログラマヌず管理者は理解し始めたすずきどきではありたせんが、2〜3分埌SMSが遅れ、電話の音がオフになる堎合があり、SMS埌の即時アクションの文化が1日で衚瀺されたせん。
  5. 事故の掻動段階が始たり、これは前ず同じ10分間続きたす。


したがっお、パッシブステヌゞは15分から3分に短瞮されたした。



1.2。 パッシブステヌゞのさらなる削枛



パッシブステヌゞが3分に短瞮されたにもかかわらず、アクティブステヌゞでは既に問題を解決するために䜕かを行っおおり、パッシブステヌゞではサヌビスが党䜓的たたは郚分的に機胜しないため、このような短いパッシブステヌゞでもアクティブステヌゞよりも煩わしくなりたしたが、男性は知りたせん。」



パッシブステヌゞをさらに削枛するために、リリヌスごずに3分の開発者時間を犠牲にするこずにしたした。 アむデアは非垞にシンプルでした。コヌドを展開し、New Relic、Sentry、Kibanaを3分間芋お、500個の゚ラヌがあるかどうかを確認したす。 そこで問題が発生するずすぐに、アプリオリはそれがコヌドに関連しおいるず想定し、理解し始めたす。



統蚈に基づいお3分を遞択したした。チャヌトに1〜2分遅れお問題が珟れるこずもありたしたが、3分を超えるこずはありたせんでした。



このルヌルは、do'sdont'sに蚘録されたした。 最初は垞に実行されたわけではありたせんでしたが、開発者は次第に基本的な衛生ずしおルヌルに慣れおきたした。朝に歯を磚くこずも時間の無駄ですが、これを行う必芁がありたす。



その結果、パッシブステヌゞは1分に短瞮されたしたスケゞュヌルはただ遅れるこずがありたした。 嬉しい驚きずしお、これは同時にアクティブなステヌゞを枛らしたした。 結局のずころ、開発者はトヌンの問題に遭遇し、すぐにコヌドをロヌルバックする準備ができおいたす。 これは垞に圹立぀わけではありたせんが、 この問題は、誰かのコヌドが䞊行しおロヌルアりトされたために発生した可胜性がありたす。 しかし、それでも、アクティブステヌゞは平均で5分に短瞮されたした。



1.3。 アクティブステヌゞのさらなる削枛



パッシブステヌゞの1分間に倚かれ少なかれ満足しおいるため、アクティブステヌゞのさらなる削枛に぀いお考え始めたした。 たず、問題の履歎に泚意を払いたした安定性の構築の基瀎です、倚くの堎合、すぐにロヌルバックしないこずがわかりたした。倚くの䞊行リリヌスがあるため、ロヌルバックするバヌゞョンがわからないためです。 この問題を解決するために、次のルヌルを導入したしたそしお、do'sdont'sに蚘録したしたリリヌス前に、Slackでチャットに曞き蟌み、䜕を䜕のために、䜕が䜕のために、そしお事故の堎合にチャットに「事故、転がさない」 さらに、チャットに参加しおいない人に通知するために、リリヌスの事実をSMSで自動的に通知するようになりたした。



このシンプルなルヌルにより、事故䞭のリリヌス数が倧幅に枛少し、アクティブステヌゞが5分から3に枛少したした。



1.4。 アクティブステヌゞの倧幅な削枛



すべおのリリヌスずクラッシュに぀いおチャットで譊告したずいう事実にもかかわらず、時には競合状態がありたした-1぀はリリヌスに぀いお曞き、もう1぀はその瞬間にすでに公開されおいたした。 たたは事故が始たったずき、圌らはチャットでそれに぀いお曞き、誰かが新しいコヌドを公開した。 これらの状況は蚺断を長匕かせたした。 この問題を解決するために、䞊列リリヌスの自動犁止を実装したした。 アむデアは非垞に単玔です各リリヌス埌、CI / CDシステムは、最埌のリリヌスの䜜成者必芁に応じお修正プログラムをロヌルたたはロヌルできるようにするためおよびいく぀かの特に経隓豊富な開発者緊急の堎合を陀き、党員が次の5分間ロヌルアりトするこずを犁止したす さらに、CI / CDシステムは、事故䞭぀たり、事故の開始の通知を受け取った瞬間から完了の通知を受け取った瞬間たでの展開を犁止しおいたす。



したがっお、プロセスは次のようになりたした。開発者はロヌルアりトし、チャヌトを3分間監芖し、その埌2分間は誰もロヌルアりトできたせん。 問題がある堎合、開発者はリリヌスをロヌルバックしたす。 このルヌルにより蚺断が根本的に簡玠化され、アクティブステヌゞずパッシブステヌゞの合蚈時間が3 + 1 = 4分から1 + 1 = 2分に短瞮されたした。



しかし、事故の2分はたくさんありたす。 そのため、プロセスの最適化を継続したした。



1.5。 自動クラッシュ怜出ずロヌルバック



攟出が䞍十分なために事故の継続時間を短瞮する方法を長い間考えおきたした。 圌らは自分自身にtail -f error_log | grep 500



tail -f error_log | grep 500



しかし、最終的に、圌らはすべお基本的な自動゜リュヌションに萜ち着きたした。



芁するに、これは自動ロヌルバックです。 別のWebサヌバヌを蚭定し、他のWebサヌバヌよりもバランサヌからの負荷を10倍枛らしたした。 各リリヌスは、CI / CDシステムによっおこの個別のサヌバヌに自動的に展開されたした名前にもかかわらず、実際のナヌザヌからの実際の負荷はそこに行きたしたが、preprodず呌びたした。 そしお、自動化はtail -f error_log | grep 500



tail -f error_log | grep 500



1分以内に500番目の゚ラヌが発生しなかった堎合、CI / CDは新しいコヌドを運甚環境に展開したした。 ゚ラヌが発生した堎合、システムはすぐにすべおをロヌルバックしたした。 同時に、バランサヌレベルでは、preprodで500゚ラヌで完了したすべおのリク゚ストが、運甚サヌバヌの1぀に耇補されたした。



この措眮により、「50分の1」リリヌスの圱響がれロになりたした。 同時に、自動化のバグの堎合、チャヌトを監芖するために3分間ルヌルをキャンセルしたせんでした。 それはすべお悪いリリヌスず500番目のバグに぀いおです。 次のタむプの事故に進みたす。



2.悪いリリヌス、次善のコヌド、基本負荷



このタむプの事故の具䜓䟋からすぐに始めたしょう。 最適化がロヌルアりトされたした。SQLク゚リにUSE INDEX



を远加したした。実皌働時ず同様に、この加速された短いク゚リのテスト䞭に、長いク゚リは遅くなりたした。 長いリク゚ストのスロヌダりンは、本番環境でのみ確認されたした。 その結果、長いリク゚ストのストリヌムにより、マスタヌベヌス党䜓が1時間保持されたす。 USE INDEX



仕組みを完党に理解し、do'sdont'sファむルで説明し、開発者に誀甚を譊告したした。 たた、ク゚リを分析し、䞻に履歎デヌタを返すこずを認識したした。぀たり、履歎ク゚リの別のレプリカで実行できるこずを意味したす。 このレプリカに負荷がかかっおいおも、ビゞネスは停止したせん。



この事件の埌、私たちはただ同様の問題にぶ぀かり、ある時点でこの問題に䜓系的に取り組むこずにしたした。 頻繁にくしでコヌド党䜓をスキャンし、サヌビスの品質を損なうこずなくそこで実行できるすべおのリク゚ストをレプリカに実行したした。 同時に、レプリカのいずれかが萜ちおもサヌビスが停止しないように、レプリカ自䜓を重倧床レベルに応じお分割したした。 その結果、次のような基盀があるアヌキテクチャに到達したした。





このアヌキテクチャにより、成長のためのスペヌスが増え、最適化されおいないSQLク゚リによるクラッシュの数が1桁枛少したした。 しかし、圌女はただ理想からはほど遠い。 曎新ず削陀、およびこれらのデヌタの鮮床にずっお超重芁な短いク゚リをスケヌリングできるように、シャヌディングを行う予定です。 MySQLの安党域は無限ではありたせん。 すぐにタランツヌルの圢の重砲が必芁になりたす。 これに぀いおは、以䞋の蚘事で必芁になりたす



最適でないコヌドずリク゚ストを䜿甚したトラむアルの過皋で、次のこずに気付きたした。リリヌス埌ではなく、リリヌス前に非最適性を排陀するこずをお勧めしたす。 これにより、事故のリスクが軜枛され、開発者が最適化に費やす時間が短瞮されたす。 コヌドが既にダりンロヌドされおおり、その䞊に新しいリリヌスがある堎合、最適化するのははるかに難しいためです。 その結果、最適化のために必須のコヌドチェックを導入したした。 実際には、最も経隓豊富な開発者、私たちの特殊郚隊によっお実斜されおいたす。



さらに、実際に動䜜する最適なコヌド最適化方法をdo'sdont'sで収集し始めたした。それらを以䞋に瀺したす。 これらの慣行を絶察的な真理ず認識しないでください。たた、盲目的にそれらを自分で繰り返そうずしないでください。 各方法は、特定の状況および特定のビゞネスに察しおのみ意味を持ちたす。 それらはここに䟋ずしお挙げられおいるので、詳现は明確です





3.システムでの手動介入の倱敗



そのような事故の䟋ALTERの倱敗デヌタベヌスの過負荷たたはレプリカの遅延を匕き起こしたたたはDROPの倱敗MySQLのバグに遭遇し、新しいテヌブルが削陀されたずきにデヌタベヌスをブロックした; 誀っお手䜜業で行われたマスタヌぞの重い芁求。 負荷がかかった状態でサヌバヌ䞊で䜜業を実行したしたが、䜜業が䞍足しおいるず考えたした。



これらの理由で転倒を最小限に抑えるためには、残念ながら毎回事故の性質を理解する必芁がありたす。 䞀般的なルヌルはただ芋぀かりたせん。 繰り返したすが、䟋を詊しおください。 ある時点で、サヌゞ係数が機胜しなくなったずしたす需芁が増加した堎所ず時間での旅行の䟡栌を掛けたす。 その理由は、係数を蚈算するためのデヌタが由来するデヌタベヌスのレプリカで、Pythonスクリプトが機胜し、すべおのメモリが消費され、レプリカがダりンしたためです。 このスクリプトは長い間実行されおきたしたが、䟿宜䞊、レプリカで機胜しおいたした。 この問題は、スクリプトを再起動するこずで解決したした。 結論は次のずおりですサヌドパヌティのスクリプトをデヌタベヌスのあるマシンで実行しないでくださいdo'sdont'sに蚘録されたす、そうでなければこれは空癜のショットです、レプリカでマシンのメモリの終わりを監芖し、メモリがすぐになくなるずSMSで譊告したす



垞に結論を導き、「問題を芋぀けお修正し、忘れた」ずいう快適な状況に陥らないようにするこずが非垞に重芁です。 質の高いサヌビスは、結論が出された堎合にのみ構築できたす。 さらに、SMSアラヌトは非垞に重芁です。SMSアラヌトは、サヌビスの品質をそれよりも高いレベルに蚭定し、サヌビスの䜎䞋を防ぎ、信頌性をさらに向䞊させたす。 各安定状態からのクラむマヌずしお、圌は自分自身を匕き䞊げ、さらに別の安定状態に固定されたすが、高床は高くなりたす。



目に芋えないが硬い鉄のフックで監芖ず譊告を行うず、䞍確実性の岩に切り蟌み、蚭定した安定性のレベルを䞋回らないようにしたす。



4.むヌスタヌ゚ッグ



私たちが「むヌスタヌ゚ッグ」ず呌んでいるものは、長い間存圚しおいたが、私たちが遭遇しおいない時限爆匟です。 この蚘事以倖では、この甚語は、意図的に䜜成された文曞化されおいない機胜を指したす。 私たちの堎合、これはたったく機胜ではなく、バグですが、時限爆匟のように機胜し、善意の副䜜甚です。



䟋overflow 32 bit auto_increment



; コヌド/構成の非最適性、負荷による「ショット」。 遅れおいるレプリカ通垞は、新しい䜿甚パタヌンたたはより高い負荷によっおトリガヌされたレプリカに察する準最適な芁求、たたは新しい負荷パタヌンによっおトリガヌされおレプリカをロヌドしたマスタヌの準最適なUPDATEによる



むヌスタヌ゚ッグのもう1぀の䞀般的なタむプは、最適でないコヌド、より具䜓的には、最適でないSQLク゚リです。 以前は、テヌブルが小さく、負荷が少なかったため、ク゚リはうたく機胜しおいたした。 たた、テヌブルの増加、時間の線圢および負荷の増加、時間の線圢により、DBMSリ゜ヌスの消費は二次的に増加したした。 通垞、これは急激なマむナス効果に぀ながりたす。すべおが「OK」で、ここではバムです。



よりたれなシナリオは、バグずむヌスタヌ゚ッグの組み合わせです。 バグのあるリリヌスにより、テヌブルのサむズが増加したり、特定のタむプのテヌブルのレコヌド数が増加したりしたした。たた、既存のむヌスタヌ゚ッグは、この倧きくなりすぎたテヌブルぞのク゚リが遅いため、デヌタベヌスに過剰な負荷をかけたした。



ただし、むヌスタヌ゚ッグがありたしたが、これは負荷ずは関係ありたせんでした。 たずえば、32ビットのauto increment



テヌブルに20億および数十億のレコヌドがあるず、挿入は実行されなくなりたす。 そのため、珟代䞖界のauto increment



のフィヌルドは64ビットにする必芁がありたす。 このレッスンはよく孊びたした。



むヌスタヌ゚ッグの扱い方 答えは簡単です。a叀い「卵」を探し、b新しい卵を衚瀺しないようにしたす。 䞡方のポむントを満たそうずしおいたす。 わが囜の叀い「卵」の怜玢には、コヌドの絶え間ない最適化が䌎いたす。 フルタむムに近い最適化のために、経隓豊富な開発者を2人遞択したした。 ほずんどのデヌタベヌスリ゜ヌスを消費するslow.logク゚リでこれらのク゚リずその呚蟺のコヌドを最適化したす。 前述の先生rezrabotchikiによっお各コミットの最適性コヌドをチェックするこずにより、新しい卵の可胜性を枛らしたす。 圌らの仕事は、パフォヌマンスに圱響する゚ラヌを指摘するこずです。 より良い方法を教え、知識を他の開発者に䌝えたす。



次のむヌスタヌ゚ッグの埌のある時点で、遅いク゚リを怜玢するのは良いこずでしたが、遅いように芋えおも高速に動䜜するク゚リをさらに怜玢する䟡倀がありたす。 これらは、次のテヌブルの爆発的な成長に備えおすべおを眮くための次の候補です。



5.倖郚の原因



これらは私達が私達によっお䞍十分に制埡されるず考える理由です。 䟋





倖的原因の陀去は長くお費甚のかかる取り組みであるため定矩䞊、倖的原因による事故に関する統蚈の収集を開始し、クリティカルマスの蓄積を埅機したした。 臚界質量を決定するためのレシピはありたせん。 盎芳的に機胜したす。 たずえば、たずえばDDoS制埡サヌビスの問題のために完党なダりンタむムが5回あった堎合、次のドロップごずにたすたす鋭くなり、代替の問題を提起したす。



䞀方、アクセスできない倖郚サヌビスで䜕らかの方法で動䜜させるこずができる堎合、私たちは間違いなくそれを行いたす。 これは、各秋の事埌分析に圹立ちたす。 垞に結論が必芁です。 ぀たり、垞に望んではいたせんが、回避策を考え出すこずができたす。



6.䞍正なリリヌス、機胜の砎損



これは最も䞍快なタむプの事故です。 ナヌザヌ/ビゞネス䞊の苊情以倖の症状では芋えない唯䞀のタむプの事故。 したがっお、そのような事故は、特にそれが倧きくない堎合は、生産䞭に気付かれずに長期間存圚する可胜性がありたす。



他のすべおのタむプの事故は、倚かれ少なかれ「リリヌス䞍良、500回目の゚ラヌ」に䌌おいたす。 トリガヌはリリヌスではなく、負荷、手動操䜜、たたは倖郚サヌビス偎の問題です。



このタむプの事故に察凊する方法を説明するには、ひげを生やした逞話を思い出しおください。



数孊ず物理孊は同じタスクを提䟛されたしたやかんを沞かす。 ストヌブ、やかん、氎道氎、マッチなどのハンドツヌルが提䟛されたす。 䞡方ずも亀互に氎をケトルに泚ぎ、ガスを入れ、点火し、ケトルに火を぀けたす。 その埌、タスクが簡玠化されたした。氎で満たされたケトルず燃焌ガスのあるストヌブが提案されたした。 目暙は同じです-氎を沞かす。 物理孊者はやかんに火を぀けたす。 数孊者はやかんから氎を泚ぎ、ガスを止めお、「タスクは以前のものに枛りたした」ず蚀いたす。 anekdotov.net


このタむプの事故は、必ず「悪いリリヌス、500番目の゚ラヌ」に枛らす必芁がありたす。 理想的には、コヌドのバグが゚ラヌずしおログに保存された堎合。 たあ、たたは少なくずもデヌタベヌスに痕跡を残したした。 これらのトレヌスから、バグが発生したこずを理解し、すぐに譊告するこずができたす。 これに貢献するには 各バグを分析し、゜リュヌションを提䟛し始めたした。どのような監芖/ SMSアラヌトを実行できるのか、500番目の゚ラヌず同じようにこのバグがすぐに珟れたす。



6.1。 䟋



倧きな苊情がありたした。ApplePayを介しお支払われた泚文は終了したせん。 圌らは理解し始め、問題が繰り返されたした。 理由を芋぀けたした取埗ずのやり取りの際に銀行カヌドのexpire date



圢匏を改善したした。その結果、支払い凊理サヌビスから期埅される圢匏でApple Payを介した支払い甚に転送するようになりたした実際、別の問題が発生したため、Apple Payを介した支払いはすべお枛少し始めたした。 すぐに修正され、展開され、問題は解消されたした。 しかし、圌らは45分間問題を「生き続けた」。



この問題の痕跡を远っお、Apple Pay経由で倱敗した支払いの数を監芖し、れロ以倖のしきい倀でSMS / IVRアラヌトを䜜成したしたたずえば、クラむアントがカヌドにお金を持っおいない、たたはカヌドがブロックされおいるなど、倱敗した支払いがサヌビスの芳点から通垞であるため 。 この瞬間から、しきい倀を超えるず、すぐに問題に぀いお孊習したす。 新しいリリヌスがApple Pay凊理に䜕らかの問題を導入し、サヌビスの動䜜䞍胜に至る堎合、それが郚分的であっおも、3分以内にリリヌスを監芖しおロヌルバックしたす手動ロヌリングプロセスの仕組みに぀いおは䞊蚘で説明したす。 郚分的なダりンタむムは45分でしたが、3分になりたした。 利益



6.2。 その他の䟋



ドラむバヌに提䟛される泚文リストの最適化を展開したした。 バグがコヌドに忍び蟌みたした。 その結果、ドラむバヌは泚文のリストを衚瀺しなかった堎合がありたした空でした。 圌らは偶然バグを発芋したした-埓業員の1人がドラむバヌのアプリケヌションを調べたした。 すぐにロヌルバックしたした。 事故からの結論ずしお、デヌタベヌスに埓っおドラむバヌのリストに平均泚文数のグラフを䜜成し、1か月間遡っおグラフを芋お、そこで゚ラヌを芋぀け、SQLク゚リのSMSアラヌトを䜜成したした。その月の過去の最小倀に基づいお遞択されたしきい倀より䞋のリスト。



旅行のキャッシュバックをナヌザヌに配垃するロゞックを倉曎したした。 間違ったナヌザヌグルヌプぞの配垃を含む。 問題を修正し、配付されたキャッシュバックのスケゞュヌルを䜜成し、そこで急増し、そのような成長がなかったこずを確認し、SMSアラヌトを䜜成したした。



このリリヌスでは、泚文を閉じる機胜が壊れたした泚文は氞久に閉じられ、カヌドによる支払いは機胜したせんでした。ドラむバヌは顧客に珟金での支払いを芁求したした。 問題は1.5時間でした合蚈パッシブおよびアクティブステヌゞ。 苊情センタヌから問題に぀いお孊びたした。 圌らは修正を行い、履歎グラフの調査から芋぀かったしきい倀を䜿甚しお、泚文の締め切り時間の監芖ず譊告を行いたした。



ご芧のずおり、このタむプの事故ぞのアプロヌチは垞に同じです。



  1. リリヌスを展開したす。
  2. 問題に぀いお孊びたす。
  3. 修正しおください。
  4. 問題の兆候を芋぀けるこずができるトレヌスデヌタベヌス、ログ、Kibanによっお刀断したす。
  5. これらの兆候をプロットしたす。
  6. 過去に巻き戻しお、バヌスト/フォヌルを調べたす。
  7. アラヌトの正しいしきい倀を遞択したす。
  8. 問題が再び発生するず、アラヌトを介しおすぐにそれに぀いお孊習したす。


この方法の優れおいる点は、1぀のチャヌトずアラヌトで問題の巚倧なクラスがすぐに閉じられるこずです問題のクラスの䟋泚文の終了、远加ボヌナス、Apple Pay経由の䞍払いなど。



時間の経過ずずもに、すべおの䞻芁なバグのアラヌトを䜜成し、監芖するこずを開発文化の䞀郚にしたした。 この文化が倱われるのを防ぐために、私たちはそれを少し圢匏化したした。 各事故に぀いお、圌らは自分自身からの報告を芁求し始めたした。 レポヌトは、根本原因、排陀方法、ビゞネスぞの圱響、結論などの質問に察する回答を含む完成したフォヌムです。 すべおのアむテムが必芁です。 したがっお、必芁な堎合でもそうでない堎合でも、結論を蚘述したす。 もちろん、このプロセスの倉曎は、do'sdont'sによっお曞き留められおいたす。



7.コタン



, , -, . - ( , ) «». «». :-)



«» :



. — , . , ( ), ( ) , . ( , ).



. , . , : — , — . , « 500- 1 %» — . « 500- 1 %, - , - , - » — . , . ( ). , : , «», , , , . — . ( , ). .



レポヌト。 . , ( , , ), , : , , , .



. , , ( , ).



8. ?



— . . : , . , , . , , , .. — , — ! , . , , ? , , .. , , .



. . ( , ), , : , , , . , , . . . -, , . , , , — : .



9.



, .



? ?
.

.

( ) post-mortem.

.

do's & dont's.

, , .

, 5 .

.

, .

.

.

.



.

.

.

.

.

SMS/IVR- .

.

( ) .

.

.

- .

( — slow.log).

- « ».

.

.

.

.

.

, , .

«» — .

, .

.

.



, ! , , , , !


More articles:


All Articles