Microsoft、Windowsの更新プログラムで問題の発生した部分だけをロールバックできる「Knows Issue Rollback」の仕組みを解説 31
ストーリー by headless
復元 部門より
復元 部門より
Windowsの更新プログラムで問題が発生した場合、更新プログラム自体をアンインストールしなくても問題の部分だけをロールバックできるという「Known Issue Rollback (KIR)」の仕組みについてMicrosoftが解説している(Windows IT Pro Blogの記事、
BetaNewsの記事、
Computerworldの記事)。
KIRで部分的なロールバックを可能にする仕組みは、バグ修正前のコードを残したまま新しいコードを追加しておき、ポリシーで新しいコードの有効・無効を切り替えるというものだ。デフォルトでは新しいコードが有効になっているが、広く影響する問題が確認されるとクラウド上で設定が変更され、Windows Update/Windows Update Businessを通じてデバイスに変更が通知される。更新プログラムをインストール済みのデバイスで新しいコードを無効化するには再起動が必要となる一方、以降に更新プログラムをインストールするデバイスでは初めから新しいコードが無効化された状態になるため、リリース後の早い段階で確認された問題を多くのユーザーは目にすることもない。
KIRは新機能のような感じで紹介されているが、実際には2019年の終わりから使われており、現在Windows 10 バージョン2004以降に提供される修正の80%はKIRによるロールバックが可能だという。バージョン2004よりも前のWindows 10でも、バージョン1809や1909など一部のバージョンではKIRをを部分的にサポートしているそうだ。KIRの仕組みとしてはセキュリティ修正にも対応可能だが、修正前のコードには脆弱性が含まれるため、セキュリティに関連しない修正にのみ使用しているとのことだ。
ブログ記事では昨年4月に提供された累積更新プログラムのプレビュー(KB4550945)で発生した問題の修正がKIRの実例として挙げられているが、説明の内容からみて12月にWindows 10 バージョン20H2で発生していたchkdskの問題の修正にもKIRが使われたとみられる。
KIRで部分的なロールバックを可能にする仕組みは、バグ修正前のコードを残したまま新しいコードを追加しておき、ポリシーで新しいコードの有効・無効を切り替えるというものだ。デフォルトでは新しいコードが有効になっているが、広く影響する問題が確認されるとクラウド上で設定が変更され、Windows Update/Windows Update Businessを通じてデバイスに変更が通知される。更新プログラムをインストール済みのデバイスで新しいコードを無効化するには再起動が必要となる一方、以降に更新プログラムをインストールするデバイスでは初めから新しいコードが無効化された状態になるため、リリース後の早い段階で確認された問題を多くのユーザーは目にすることもない。
KIRは新機能のような感じで紹介されているが、実際には2019年の終わりから使われており、現在Windows 10 バージョン2004以降に提供される修正の80%はKIRによるロールバックが可能だという。バージョン2004よりも前のWindows 10でも、バージョン1809や1909など一部のバージョンではKIRをを部分的にサポートしているそうだ。KIRの仕組みとしてはセキュリティ修正にも対応可能だが、修正前のコードには脆弱性が含まれるため、セキュリティに関連しない修正にのみ使用しているとのことだ。
ブログ記事では昨年4月に提供された累積更新プログラムのプレビュー(KB4550945)で発生した問題の修正がKIRの実例として挙げられているが、説明の内容からみて12月にWindows 10 バージョン20H2で発生していたchkdskの問題の修正にもKIRが使われたとみられる。
ひらめいた (スコア:0)
あらかじめ10年分くらいのアップデートを配信しておいて、少しずつ有効化していけば
仕事しているように見せかけて10年間遊んで生きていけるんじゃね？
Re: (スコア:0)
不可能であるということに目をつぶれば完璧な考え方ですね…
Re: (スコア:0)
この辺の大企業は何もしないでも一定期間遊んでられる蓄えは常にあるんだろうなあ。
Re: (スコア:0)
あらかじめ10年分くらいのアップデートを配信しておいて、少しずつ有効化していけば
仕事しているように見せかけて10年間遊んで生きていけるんじゃね？
んで仕様変更で10年分のパッチが水泡に帰すまでがテンプレ
# 未知を既知にするためにまずはタイムマシンが必要ですね
複雑なロールバックシステム (スコア:0)
複雑化したシステムファイルのロールバックは何気に難しい、、、
本当にできるのかな？と思う次第（昨日できには昔からあるけど
Linuxシステムでのパッケージ管理も昔に比べて安全に
ロールバックできるようにはなってはいるが、結構ごり
押しのゴリゴリでやっている部分があるけど、まぁまぁ
実際にやるときは怖いし
Re: (スコア:0)
アップデートが適用されない原因すらあやふやなのに
部分ロールバックが安全にできるとは到底思えないね
ひっそり適用されてるというこのツギハギ更新が
おま環問題をばらまいてるんじゃないのか？
2019年の終わりから (スコア:0)
1909配信のための仕組みを応用したのかな?
ソース記事を読まないのはスラドの流儀だから (スコア:0)
更新プログラム自体にも依存関係ってあるものだと思うんですけどそのへんどうなんですかね。
で、そういうの考え出すとますます複雑になってロールバックすると更新システムのバグで〜、
みたいな話になる定期、になるのでは、っていう。
もう何年も運用されてるみたいなのでそういうのは大丈夫なんでしょうけど。
Re: (スコア:0)
そもそも更新プログラムの組み合わせ爆発を避けるためにすべての更新プログラムを累積的に強制適用することにしたという話はどこ行ったんですかね
Re:ソース記事を読まないのはスラドの流儀だから (スコア:1)
といっても更新プログラムは一つのパッケージではなく複数の更新パッケージの集合体のままだったわけで、ユーザー側で個別に選択してアップデートできなくすることで組み合わせ爆発は大幅に減らしている。
提供側の管理下で個別にロールバック可能にすることと矛盾しているわけではないよ。
Re: (スコア:0)
あと機能更新ごとにパッチ適用の履歴がすべてリセットされるのも大きいと思う
新たな脆弱性フラグ (スコア:0)
消し忘れの脆弱性のある旧コードを突く攻撃とか
パッチ当ててる意味ないじゃんみたいな事態が予想されますね
そもそもInsider Previewでのテストが
機能していないことが主因なので
Insider Previewでのテストインセンティブや
それを通したバグを含む発見報奨の仕組みや額に手を入れたほうが
プラットフォームとしてはマシになってくんじゃないかな
また事故る (スコア:0)
どこかパクって実装するまではいいが
いつも詰めが甘く事故る。
導入する前にテストを十分にしてくれ
MSでは (スコア:0)
コード書く奴はテストは一切しないのかしら
コンパイル通ればOKって感じ？
特殊な環境、特殊な状況でのみ起こる不具合ってんじゃなく
ハナから全く動かないような代物を平気な顔でリリースしやがるよな、IME周りとか
21xxx系ではBDAを完全にぶっ壊しやがったし
Re: (スコア:0)
ん？何言ってるんですか？コンパイル通ればバグがあるわけないじゃないですか。
Re: (スコア:0)
プロダクトとしてのレベルでは、不具合は品質管理の部署の問題で一般ユーザーがコーダーを責めるのは間違い。
リリース前に単体レベルの問題でテスターがコーダーにキレるのはいいが、リリースされたものはテスター側に責任がある。
常識的には、ハナから全く動かないような代物はリリースされない。あなたの言うようにテストの工程が存在しないなら起こり得るが。
Re: (スコア:0)
各個別プログラムのバージョンの組み合わせの他にも設定・オプションの組み合わせもあるし
タイミングやら使い方の組み合わせも無限だし 有限時間でテストできる部分なんて極一部分なんだろうなぁ…、ホントどうテストしてんだろ？
Re: (スコア:0)
不具合におま環と返すだけの簡単なお仕事です
Re: (スコア:0)
おま環wwwww
MacBook、USB-Cハブとの接続で破損
macOS、ロック解除ボタン連打でrootログインできる致命的な脆弱性
macOS暗号化メールの一部が平文保存されるバグ発見
macOS、パスワードのヒントボタンを押すと、パスワードを表示する脆弱性
特定の文字列受信でAppleのOSをクラッシュさせるバグ、また見つかる
iPhoneなどの旧モデルに「修正不能」な脆弱性
Apple、macOSでメールが解読されてしまう脆弱性
macOS アップデート後に「大容量ファイル転送中にクラッシュ」等の報告相次ぐ
macOS、修正した重大な脆弱性が「復活」するバグ
またも、macOSにどんなパスワードでも通るバグ発見
m
Re: (スコア:0)
また4年前のコピペマンが発狂してんの
Re: (スコア:0)
てかMSのが悲惨なのは、リリースするだけなら安全なものを、勝手にアップデートして、その挙句に不具合起こすところな。
で、しかもこのアップデートは強制だっていうのだから終わってる。
ロールバックのしくみ以前に強制アップデートシステムの方をどうにかしろ。
Re: (スコア:0)
最近Linux Mintの話題が出たばかりなのに何言ってんだ？
一般人や自称分かってる人の多いWindowsでアップデートを任意にすると全世界的に問題になるから強制アップデートにしてるんだろ。
本当に分かっている人が使用しているならWindowsUpdateだって任意にできる。
「強制アップデートシステムの方をどうにかしろ」なんて言ってる時点で、お前は何も分かってない愚か者ってこった。
Re: (スコア:0)
コード書く奴はテストは一切しないのかしら
コンパイル通ればOKって感じ？
エラー吐く箇所をすべてコメントアウトしました
とかだったりして
根本的問題 (スコア:0)
そもそも、ロールバックなんかせず社内テストの段階で炙り出せるように徹底的に依存関係と影響度を単純化するべきでは？
別コメでも既出だけど、そもそもこういうまどろっこしいパッチ適用有無の混在を避けるために強制アップデートという仕様にしたはずなのに……
Re: (スコア:0)
マイクロソフトとは無関係な某外資系メーカーでの話ですが、そんなことができるんなら最初からやってます。
「弊社ではこれ(ライブラリとかランタイムとか)を推していくことになったから必ずこれを使え(いらんやん・・)」とか、
「ん？この機能はこっちにあるよね？何でこれを使わないの？(似てるだけで全く違う機能なのに・・)」とか、
「あいつ(特定部門の上長)嫌いだからこのライブラリは使用禁止な」とか、
「スクリプトでのリリースは前例がないからコンパイル型言語で作り直して」とか、
依存関係や影響度が複雑なのは、営業的な理由と社内政治的な理由がほとんどだったりします。
マイクロソフトさんも社内が複雑なんだと思いますよ。
いつまでロールバック可能なのか (スコア:0)
新旧を切り替えるコードの実装を嘗てやっていた事があるけれど、管理が複雑になるのは言われなくてもわかるだろう。
後のアップデートでは過去の新旧コード自体が不要になったり、新コードのみが対応可能な追加機能込みだったりで、倍のコードに分岐が増える遅延もあって組み合わせバグも発生するようになり、リリース後半年経ってもクレームのない新コードの旧コードを取り除くようにしたら、1年以上経ってから旧コードがあればと思うような潜在バグが見つかって以降は、テストの自動化でテスト項目を増やし、ストレステストも負荷を軽くしたり重くしたり、といったテスト多角化以外は無駄だと思えるようになった。
Re: (スコア:0)
ユーザーの権限でロールバックできるわけではない。MSの都合でリリース後にバグがめっかったら「んぢゃ、戻すか・・・。」ってやるだけ。
バグではなく仕様です。となれば放置に決まってんがな。
例えバグでも、次の大型アップデートでは修正されます。とかね。
どうせ2年しかサポートしないからツギハギでもなんとかその間凌げばＯＫみたいな。
update自体の品質向上施策 (スコア:0)
https://www.nichepcgamer.com/archives/category/windowsupdate [nichepcgamer.com]
ほぼ毎月何かしら不具合起こしてる状態が普通になってしまってるの、どうにかしてほしい。