ADのDFSRを壊して直す。
あけましておめでとうございます。
さて年末年始のお片付けということで自宅Hyper-Vで検証環境として眠ったADを整理しよう。
業務本番環境とかで見かけると死にたくなるような状況ですが、 自宅なのでヘーキヘーキ。
まぁ別に壊しちゃって全削除でも何ら問題ない環境ですが、 意図的に壊れかけの状態から復旧手順のテストをするのもめんどくさいので、 せっかく機会だと思ってトラシューしてみた。
repadmin /showrepl
レプリケートに失敗してますね。まぁそうだろう。
強制レプリケートでどーん。
してみましたが拒否られる。
多分この辺。とおもって一通りためす。 Active Directory レプリケーション イベント ID 2042 (このコンピューターがレプリケートされた後、長すぎます) - Windows Server | Microsoft Docs
壊れているほう（上書きしたいほう）に入って実施してみるも拒否られる。
何が起こっているか？ そんな時はこちらへ。
DCDIAG /TEST:CheckSecurityErrors 便利。
AD昇格した際に作られる諸々必要なDNSのレコードが消失している。っぽい？ レプリ元がFSMOのADではなく、自身のローカルDNSサービスを参照しており乖離が発生していた模様。 参照先をFSMOに合わせることで解決。←ここが案外はまりポイントでした。
これでエラーの内容がサービスプリンシパルが異なる。という内容に変わる。 が、何度確かめてもサービスプリンシパルはあっている。
上書きされる側（FSMOじゃないほう）でkdcのサービスを止める。
net stop kdc
この状態で再試行すると成功した。
ただレプリケートは依然、トゥームストーンがうんぬんのエラーで連携できないので↓のレジストリフラグ１を０に。
あと、こっち レジストリ キー: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Allow Replication With Divergent and Corrupt Partner をDWORDでレジストリに追加して１にする。（とても強力。）
repadmin /syncall
なおったー！
諸々チェックは必要ですがお掃除完了。
本番環境だとそうそう壊れて１８０日以上放置されるとかないと思いますけど、 直そうと思えば直せた。
久々に楽しかったｗ
下
SaaSを使いこなすために
さてクラウドサービスを使いこなすと言った際に、IaaS、PaaS、SaaSと言うものがありますが 手っ取り早く一人のユーザーとして価値を得られるのはSaaSかと思います。
IaaSやPaaS、もう少し拡大するとKubernetesやOpenShiftも凄く便利ではあるんですけど アプリの開発やインフラのメンテは必要ですので敷居が高い。
一方、SaaSは価値が得られるまでの期間が短い、敷居が低いのがメリットだと思います。
ただし敷居があまりにも低いので悩ましい状況も発生していて 何故導入するのか？と言う議論、得たい利便性についてはどうしても、 著名なプロダクトが有する機能の紹介に止まっているのでは？と感じています。
例えばOffice365やGSuiteです。 以前から言われていることですが、クラウドの比較表を作るのは不毛だなと思います。
著名ツールの実力をしるのは良いことですし、情シス担当者間のコミュニケーションとして へーそうなんだ！今度試してみようかな！と言うコミュニティでの情報交換は有益だと思います。
Aさん：GSuiteのスプレッドシートだと複数ユーザーで同時共同編集ができて便利だからGSuiteにしました！！ Bさん：いやいやOffice365のExcelもそれでますよ！
みたいな。
でも実際に現場に、どっち入れる？どう使わせる？というオーナーシップをとる際に あまりにも便利な機能が多い故にHowにばかり思考が集中する傾向があるなと感じています。
ユーザーストーリーやユーザーイベントを検証しなくても結構つかえてしまうので、 コミュニケーションや意思決定と言ったWhyがブラックボックス化するのを感じます。
便利なツールを知ることは大切ですが、多機能だから、とか、流行ってたから！とか やめた方がいいですね。
デメリットとして顕著に現れるのは、グループウェアの導入を推進した人がいなくなった 引き継がれた後任を任命する時です。
何故導入されたのか、腹落ちしない担当者が地獄を見ます。 如何せん現場に導入してしまっているので、今更ツールの変更や廃止もできない状況になりがちです。
じゃあどうすればいいと考えているのか？ですが
基本的に、著名な機能を知ると同時にやユーザーのペルソナを考えて、 便利に利用できるイベントストームの仮説を立てましょう。
例えばとてもザックリですが。 私はユーザー会でのプレゼンテーションを作ろうと思っているAです。
1.ライセンスを気にしなくて良くかつソコソコ使い勝手のいいテンプレート豊富なサンプルから選んで利用したい。 2.構成図とかを描きたいので人やパソコンなどの基本的なアイコンセットが充実していると作りやすい方がいい。 3.プレゼン会場にはパソコンを持ち込んでプロジェクターに写すことになるが回線状況が直前までわからないのでローカル端末に資料を準備しておきたい。
などです。
アイコンセットが標準で用意されているか？などは機能的には大したことないですが Aさんのユーザービリティとしては大切です。
プロダクト開発ではユーザーストーリーマッピングと言う手法があります。 SaaSなので機能開発は必要ありませんが、SaaSを組織で有効活用するため、改めてなぜ既存のSaaSが導入されているのかを整理するために 以下のような手法を参考にしてみるは有益だと思います＾＾
今後、いわゆるプログラミングによるプロダクト開発以外の場面にアジャイル開発のエッセンスを取り入れる推進活動を実施していきたいと考えています。
”サポートを使いこなす技術”を身につけるために
あけましておめでとうございます。今年もよろしくお願いいたします。
2019年末に ２つの記事を書きました。
１．(ITベンダー)サポート使いこなし宣言
２．(ITベンダー)サポート使いこなし宣言の背後にある原則
経緯
クリスマスの日に宇田センセーのツイートに書いてみようかな？と思ったのが始まり。
TLにあつまる議論を確認
どんな事を書いても、読む人は元々ひどい人じゃないので・・・というあきらめに近い意見。一理ある。
当事者意識がない人、とか、本質じゃないことに固執する。
このあたりの感覚も共感するとともにサポートにおける”本質”とは何か？ 認識のズレは議論すべき価値がありそうだなと思いました。
技術的なHow toについてはある程度既存のドキュメントが充実している
技術的なサポートを円滑に進めるHow toについてはTLでよだれいぬさんが紹介しているAWSのサイトとか参考になるなと思いました。 若干AWS特有な表現や事情もありますが、 読み替え可能な一般的な注意点だとおもいます。
正直、これ読んどけば良いという感はある。
具体的なHow toではなく、ユーザー側の価値基準や心構えを書きたい
ぼんやりと、以下のようなことを考えながら書きました。
- 物事迅速に進めるための心構えとしてアジャイルソフトウェア開発宣言は参考になるし、開発者以外にもぜひ一度読んでもらいたい。
- 参考にはなるが、読み替えた方がはまりやすい表現も多いので少し手を入れよう
興味がある人は以下も読んでみてください。
私は大手インフラ系ユーザー情シスとして、またはパートナー企業として様々なITベンダーと取引してきました。
割と早めにテクニカルリード的なポジションになったことから技術的な相談窓口となり、 大小さまざまな課題に対してITベンダーのサポートの力もお借りしつつ解決してきました。
結果として、私の不勉強、時には製品のバグ等原因は様々でしたが、 チームとして取り組む際に嫌なコミュニケーションをする人が多かった。
１．エンドユーザーからのクレームをサポートに伝え、どうしてくれるんだとプレッシャーをかける人
２．復旧に時間がかかっているのをサポートの回答が遅いからだと責任転嫁の言い訳をする人
３．既存の運用手順に無いログの取得などは出来ないとサポートへのログ提供依頼に非協力な人
４．とりあえず直せ！と怒鳴る人
もちろん私たちユーザー企業もIT製品、ITサービスを導入して提供しているサービスの担当者であり、そこにはエンドユーザーがおり、一刻も早く状況を改善しないといけないわけで、むしろエンドユーザーからは怒号が飛んだりするわけで・・・。
怒り、焦り、憤り、など感情が出てくることはあります。
が、そこはぐっとこらえ。 エンドユーザーに一刻も早く、サービスを再開するために まず冷静に優先して解決すべき課題は何かを整理したうえでサポートエンジニアに共有した方が結果として迅速に課題が解決される。
また優先度に応じた適切なサポートプランや体制を整え、 必要に応じてステークホルダーの協力を仰ぐのが依頼側の最良だと考えています。
これまでのサポート活用の経験からサポートを使いこなす上では 報・連・相の”相談”ができる関係を築くことが迅速な課題解決、 サポートを使いこなす技術の根幹だと考えています。
本来複雑な課題をシンプルに整理して、サポートに解決を依頼すべきです。 その場合は、課題の報告、状況の連絡だけで1ターン回答が得られる場合も多いです。
しかし、どうしても複雑な課題の解決の場合は、サポートエンジニアと”相談”し課題を整理することから高度な製品知識が必要な場合もあります。
そもそも複雑な事象の場合は課題の"本質"について共通認識を形成することすら容易ではありません。
サポートエンジニアに対して威圧的なコミュニケーションを行うと”相談”ができなくなり、結果として課題解決が遅れます。または、”本質”の認識のズレが後々大きな不満となります。
"相談"というのは非常に高度なコミュニケーションだと考えています。
課題解決まではサポートエンジニアも含めてOne Teamであることが大切であり、 不信をもってサポートに依頼するのは避けた方がよいです。 むしろ、率先してサポートエンジニアの心理的安全を確保するくらいがちょうどよい。
原因が製品バグで不利益を被っているかもしれません。 「そういう謝罪とか、今はどうでもいいから状況の改善に集中しましょう。」
ただ、間違ってほしくないのは過剰にITベンダーの肩を持つわけではないですし、 原因究明や責任追及が無駄だと言っているわけではないです。
心理的安全を確保したのにサポートの品質が良くないだとか、 そもそもお粗末な製品バグが多発するとか、バグではないかもしれないけど製品の理解が難しすぎるとか。
我々ユーザー企業はエンドユーザーにより良いサービスを低価格で提供する 手段としてIT製品やサポートサービスを利用しているのです。目的を見失わないようしましょう。
もし自分たちに適したサービス、製品じゃないと感じたら、 目の前の課題が落ち着いたのちに保証や賠償、製品やサービスの乗り換えを実施すればいいのです。
それはそれ、これはこれ。
私は去年の11月から渋谷のメガベンチャーの情シスとして働いています。
今後も様々なベンダー様にお世話になるかと思いますが、 その際はよろしくお願いいたします。
(ITベンダー)サポート使いこなし宣言の背後にある原則
私たちは以下の原則に従う
顧客（エンドユーザー）へのサービス支障の回避を最優先し、
課題解決の優先順位をコントロールします。
サポートエンジニアからの調査依頼については、たとえ手順書の作成や
前例の無い調査ツールの導入承認など社内手続きが手間であっても歓迎します。
サポートエンジニアを味方につけることによって、迅速な課題解決と
社内の技術力を引き揚げます。
ログの提供依頼があった際はできるだけ短い時間で取得し提供します。
すぐに提供できない場合は提供予定の時期を伝えます。
ビジネス側のインパクトや課題認識については共有し
適切な緊急度、サポートプランによる対応を依頼します。
課題解決の意欲に満ちた人々で社内側の体制をととのえます。
担当者にはサポートエンジニアの提案を検証する環境や支援を与え
課題が無事解決されるまで彼らを信頼します。
サポートエンジニアに情報を伝える最も効率的で現実的な方法は
電話です。ただし苛立ち、怒り、といった感情を伝えるのは避けるようにします。
効率的かつ迅速な課題解決こそが最も重要な目的です。
過去にサポートに問い合わせた内容を
社内のナレッジマネジメントに組み込むことでサポートエンジニアを
使いこなす技術の持続可能な改善を促進します。
技術的卓越性と優れたコミュニケーションへの不断の注意が
課題解決への機敏さを高めます。
シンプルさ（ムダなく最優先の課題をサポートエンジニアに依頼する）が本質です。
最良のサポートリクエストから課題解決に至るプロセスは、
サポートエンジニア、社内担当者、ステークホルダーの協調から生み出されます。
もっと効率を高めることができるかを定期的に振り返り
それに基づいて自分たちとサポートエンジニア間のやり方を最適に調整します。
<参考>
(ITベンダー)サポート使いこなし宣言
私たちはITプロダクトの運用における課題解決、 あるいは課題解決を手助けする活動を通じて より良いサポートの使いこなす方法を見つけ出そうとしている。 この活動を通して、私たちは以下の価値に至った。
価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。
<参考>
CISSP取得を目指して:コントロールフレームワークについて
ちょこちょこ勉強した内容を残しておこう。
以下の本を試し読み中。なかなか実務にも使えそうな体系だった知識が得られそう。 https://www.amazon.co.jp/dp/475710376X/ref=cm_sw_em_r_mt_dp_U_GfSwDb7G152EH
セキュリティフレームワークにつて
組織でセキュリティ要件を満たすためにコントロールフレームワークを採用することになるよ。
セキュリティフレームワークはISO27001やNIST SP 800-53 Revision4 があるけれども いずれにしても次の性質がある。 １．一貫性 ２．測定可能 ３．標準化 ４．包括的 ５．モジュール化
NIST SP 800-53 Revision4 は１９のファミリーと２８５のコントロールで構成される。
個人的に逆に避けた方がいいんだなと解釈したアンチパターン
１．一貫性がなく、特定の手法や声の大きい人によってセキュリティ対策が変わる。 ２．測定ができないためにルールが守られているのか、ルールを策定した有用性もわからない ３．標準化がなされておらず比較ができない。指針がないので差を検知できない ４．包括的範囲が考慮されておらず組織固有の拡張性がない ５．モジュール化されておらず、部分的な変更ができない
