[過去ﾛｸﾞ] Rust part30 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
827(1): 06/16(月)19:45 ID:GmbZlZxT(2/2) AAS
>>823
panicにするかどうかを決めるのはサーバーを実装する側じゃなくてサーバーを使うユーザー側だろ。
Linusじゃないけど、サーバー側がランタイムエラーでパニックを発生させるのは根本的に問題がある。単にエラーを返すべき。
828: 06/16(月)19:53 ID:xdTbb2+R(1) AAS
Rustは絶対安心安全なんだよ
829(1): 06/16(月)22:35 ID:GFXQS+aF(1) AAS
>>827
もちろんあるべき姿としてはエラーを返すなりフォールバックさせるなりすべき
だけど現実はヌルポでエラーも返さずクラッシュさせてたわけでRustに置き換えればpanicで落としてたのと同じようなもの
つまりRustを使っていれば防げたかというと今回のケースは防げなかった可能性が高いということ
830: 06/16(月)23:23 ID:n/id3DH6(1/2) AAS
Rustを使えば防げただろう
831(1): 06/16(月)23:25 ID:n/id3DH6(2/2) AAS
>>824
そういう時はこれ
[lints.clippy]
unwrap_used = "deny"
832(1): 06/17(火)07:28 ID:nAKE0zH5(1) AAS
>>829
ならpanicさせる>823の考えは間違いだね。
rustも安全性を標榜するならpanic禁止モードを用意すべきだわ。
833: 06/17(火)08:53 ID:wIiKTA/n(1) AAS
DoS攻撃脆弱性でregexのCVEがあったけど
関連サービスの事を無視して自分勝手にpanicしちゃったら同じ脆弱性だよね
834(1): 06/17(火)09:28 ID:qKSR12sf(1) AAS
ヌルポ騒動が起きるたびにRustの重要性が引き上がる
835(1): 06/17(火)09:35 ID:9ReeLirD(1/2) AAS
>>834
ポリシーの内容をチェックして。受け入れ可能じゃなければResultでテキトーにErr返したら済んだんじゃないの？
パニックさせる必要ほんとにあったと思ってる？
836: 06/17(火)10:10 ID:ArcAimKK(1) AAS
>>835
それでもこの件では障害になることには違いないのでは
クラッシュはしないかもしれないが
837(1): 06/17(火)10:27 ID:HytcwfDv(1/2) AAS
Rustで書くなら関数は必ずResultもしくはOptionを返すことになり、上位で処理される
838(1): 06/17(火)10:32 ID:Q1H3y5Wh(1) AAS
>>837
>>822にもあるけど
> Optionをunwrapしていいのは常にSome自明時と
その「自明」をコンパイラが静的分析するか>>831がデフォルトじゃないかぎり
隠れ unsafe
839: 06/17(火)10:35 ID:HytcwfDv(2/2) AAS
>>838
unwrapは使われない
?オペレータで上位へ委託するか
match / if let等で処理される
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
上下前次1-新書関写板覧索設栞歴
あと 146 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.012s