[過去ﾛｸﾞ] Rust part30 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
840: 06/17(火)10:41 ID:wEWjoXoE(1/2) AAS
このGoogleの件に関して言うなら、ポリシーの読み込み失敗即ちロールバックなんだろうからpanicは妥当
起動時に必須の環境変数が無い場合にpanicさせるようなもんだね
841: 06/17(火)10:46 ID:ya3T3y3J(1/2) AAS
panicで全体を止めたくない時はUnwindSafeな処理単位をcatch_unwindで実行すればいい
使ったことないけど
842(2): 06/17(火)10:51 ID:gnbFtFWo(1) AAS
>>832
ヌルポでクラッシュさせてたのは間違いではなかったとでも？
>>823はヌルポでクラッシュさせてた人たちの認識
その人たちが仮にRustを使ってたら同じようにpanicで落とすだけ
つまりRustを使っていたとしても障害は防げないという話
それに今回の障害を見てエラーハンドリングしていれば問題なかったと考えるのは短絡的すぎる
一番の問題点は一サービスの一コンポーネントがクラッシュしただけであらゆるサービスが全面的にダウンしたという点にある
だからあらゆるコンポーネントを絶対panicしないように作ろうとするよりも一コンポーネントがpanicしたとしても全面的なシステムダウンに繋がらない仕組みを作ろうと考えることが今回のような障害を防ぐための第一歩
843: 06/17(火)10:56 ID:tkXXIxpc(1/2) AAS
>>842
まともなシステムはそれだな
プロセスが落ちてもハンドリングされる
844: 06/17(火)10:58 ID:tkXXIxpc(2/2) AAS
異常状態のままプロセスが走り続けるよりもpanicなどでプロセス終了が正しいシステム構築
845: 06/17(火)11:09 ID:QpxoSzQp(1) AAS
異常状態のまま動き続ける言語よりさ
panic or エラー処理されるRustが良い結論は変わらんよね
846(1): 06/17(火)11:13 ID:wEWjoXoE(2/2) AAS
>>842
Google Cloud APIのコントロールプレーンのコアコンポーネントはさすがに一サービスの一コンポーネントとかいうレベルじゃないよ
OSのカーネルみたいなもん
こんなのヘタに誤動作を続けられたら会社が吹き飛ぶようなセキュリティ事故に繋がる可能性もあるわけで、死んでくれた方がマシ
847: 06/17(火)11:52 ID:e/HQQ23L(1) AAS
ワンワンパニック
848(3): 06/17(火)12:50 ID:ya3T3y3J(2/2) AAS
Javaで
if (value == null) {
throw AppException();
}
を書き忘れるのとRustで
let Some(value) = opt_value else { return Err(AppError); }
の代わりに
let value = opt_value.unwrap();
と書くのは発生リスクが全然違うと思うんだけど
Javaでうっかりnullチェックを忘れる人はRustでもうっかりunwrapを使うものなのか？
849: 06/17(火)13:10 ID:aeCwWEdf(1) AAS
>>848
本人判断で「自明」と決めつけて意図的にunwrapを使うのでは
850: 06/17(火)13:36 ID:gAVRJIie(1) AAS
>>822によれば
本人判断で「panicで落ちていい」と決めつけて意図的にunwrapを使うパターンもある
851: 06/17(火)14:21 ID:w2F36Aoo(1) AAS
>>848
Rustでは必要により明示的にpanicさせる.unwrap()とコードを書いた時のみpanicが起きる
意思が必要
852: 06/17(火)15:48 ID:FL91roa2(1/3) AAS
>>846
クラッシュしたのはコントロールプレーンの一部であるポリシーチェックシステムのさらにその一部のバイナリ
もっと言えば問題が起きたのはそのまた一部のクォータチェック部分
クォータチェックができなければGCPの全サービスを落とすべきというビジネス判断としてはなくはないがIncident Reportを見る限りGoogleはそうは考えてない
853: 06/17(火)16:05 ID:UZ5mCAEQ(1) AAS
Rustにしとけ
続行不可能で意図的にpanicさせるか
きちんとResult/Option処理するかになる
854(1): 06/17(火)16:27 ID:9ReeLirD(2/2) AAS
リリースしてから実際にポリシー変更が発生するまでの2週間、
テストやりこんで最後のバグだしするまでの時間とみなすか、
リリースヨシ！と思ってたかだよな
リリース後も2週間頑張ってテストやったけど境界条件探すの下手くそで見つけられませんでした、で通るかな。自分のことのようにゾッとする
855: 06/17(火)17:05 ID:FL91roa2(2/3) AAS
>>854
プログラムの変更とポリシーデータの変更は責任者も管轄組織もプロセスも違うんだと思う
ポリシーデータのほうはビジネスよりの組織が管轄というのはよくある話
なのでDev的にはリリースヨシ！
改善点の2点目に「Regardless of the business need for 〜」とあるからOpsはBizの政治力で本来とは違うプロセスを強制させられたのかもしれない
856: 06/17(火)18:12 ID:FL91roa2(3/3) AAS
ここに内部事情を含めていろいろ書いてあった
外部ﾘﾝｸ:news.ycombinator.com
857(1): 06/18(水)00:29 ID:1jrMASAC(1) AAS
ここでの議論と同じだね
Rustでpanicするの明示的にpanicを起こすコードを書いたときだけ
858(1): 06/18(水)01:06 ID:aQwOTYhv(1) AAS
>>857
>Rustでpanicするの明示的にpanicを起こすコードを書いたときだけ
ここでもHNでもそんな議論はされてない
ただ複オジが連呼してるだけ
859: 06/18(水)01:09 ID:ZwZRjmCs(1) AAS
さっさとC++捨ててRustにすれば防げたのにな
860(1): 06/18(水)01:12 ID:SA0JPy/4(1) AAS
>>858
初心者は今回のこのまとめを見るといい
外部ﾘﾝｸ:news.ycombinator.com
861: 06/18(水)02:58 ID:vm71nNgD(1) AAS
Googleの事案なんてどうでもよくてインシデントにかこつけてRustの布教がしたいだけ
だから何を書いても無駄
862: 06/18(水)06:20 ID:KrGEp9Dg(1) AAS
Rustを採用していれば防げた事案
863(1): 06/18(水)09:57 ID:NQ+tIPxW(1/3) AAS
>>848
本質は同じ
書き忘れではなくロジカルな思い違いもある
ここでnulｌはないやろとここErrはないやろは同じで思い込みだから
言語によって優劣とかじゃなく人間の限界がある
864: 06/18(水)10:09 ID:4yVSzLnj(1) AAS
>>863
全く違う
unwrap()はNone時にpanicを起こすための関数
書き忘れでpanicしない
865: 06/18(水)10:20 ID:NQ+tIPxW(2/3) AAS
＞ 書き忘れではなくロジカルな思い違いもある
866: 06/18(水)10:31 ID:GRTFL2K0(1) AAS
panicさせてはいけないプログラムでpanicさせる関数を呼ぶバカはいない
reviewでもバレる
867: 06/18(水)10:49 ID:NQ+tIPxW(3/3) AAS
メモリリークさせてはいけないぷろぐらむでめもりりーくさせるばかはいない！
868: 06/18(水)11:01 ID:Ulz+jHl5(1) AAS
Rustを使えばメモリリークも未定義動作もなく安全安心よ
869: 06/18(水)11:23 ID:lQpFkqVW(1) AAS
haskellと比べて、unwrapが気軽に使えすぎる気はする
上下前次1-新書関写板覧索設栞歴
あと 133 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.017s