はじめに
まず、私は今発表されているスケジュールでの日本版サマータイム導入は不可能と考えています。
以下の記事はよくまとまっていますが懸念点など自分なりにまとめてみました.
サマータイム導入には反対だが、サマータイム導入に必要なことを考えた
サマータイムを2年後に導入すると仮定してみて、運用とかサポートとかの観点であんまり議論されてなさそうな点を思いつくままに書いてみます。
- マルチベンダ対応
- ハードコードされた機器や設定への対応
- サマータイム以前にEOSになった機器
- サマータイムを考慮してない独自ログとか
- 深夜時間帯の運用作業
色々書きますがそんなの時代遅れの杞憂だというのならいいんですが。
1. マルチベンダ対応
日本のサマータイムに対応するのに各ベンダが各自で開始日と終了日指定してやるでしょうが、結局解釈の違いとかで問題が出てくると思います。
ベンダを統一して導入している所は各ベンダだけでいいだろうけど、官公庁とかも含めて大抵はマルチベンダで運用されています。
その実地テストは各ベンダからリリースされた物をまって組み合わせてテストするだろうけど、2020年では十分テスト出来ない状態で突入しそうです。
2. ハードコードされた機器や設定への対応
ハードウェア内で決めうちされていたり、後からのアップデートを考慮されていないという場合があります。
この場合パッチもあてられないしリプレースも予算とかの関係で無理です。
ベンダから正式対応は出来ないのでなんらかの別手段でサマータイムに対応する必要があります。
対応によってはサポート外運用になるおそれはあります。
ソフトウェア等でうまいことカバーしないと駄目でしょう。
3. サマータイム以前にEOSになった機器
EOSだけど、お客様判断で使い続けるハードウェアは結構あります。
この機器に対するファームウェアとかドライバとかのパッチってEOS後は普通出ませんしサマータイム対応はユーザ責任という事になりそうです。
政治的に対応するというベンダーも出てくると思いますが一般的には巨大なユーザじゃないと対応してもらえません。
EOS後の延長サポート代行の会社はいくつかあるけど、対応は難しそうです。
4. サマータイムを考慮してない独自ログとか
サマータイムの開始、終了を跨いだ時間に対し、OS側での対応はベンダからパッチで出る事は期待したい。でも独自なアプリケーションとかで直接イベントの時間をテキストでログに書く形式だとサマータイムを考慮した仕組みは必要です。
今からの対応ではなんらかの変換の仕組みを組みこんだ監視エージェントソフトなどで対応する必要はあります。
5. 深夜時間帯の運用作業
サマータイムの切替日って結局人が起きていない深夜に時間をズラしたりします。
運用しているシステムのバックアップとかリブートとかの運用作業って結局深夜から業務がはじまる2時間前位に終わらせるみつもりで運用するけど、サマータイムの切り替えの2時間の誤差を考慮してその日は運用しないとダメです。
結論
結局は「運用でカバー」しか無いですな。
そして対応する予算も確保も難しいので「オーバーデリバリ」でしか対応出来ないですね。