ボックス内の XNUMX つ (可能な場合) とドキュメント内の全員 (常に)。
IT の文脈では、"two in a box" は、冗長性と信頼性の向上を提供するために連携して動作するように設計された XNUMX つのサーバーまたはコンポーネントを指します。 この設定により、XNUMX つのコンポーネントに障害が発生した場合に、別のコンポーネントがその操作を引き継ぐため、サービスの継続性が維持されます。 「XNUMX つを XNUMX つに」することの目標は、高可用性と災害復旧を提供することです。 これは、組織における人間の役割にも当てはまります。 ただし、めったに実装されません。
関連する Analytics の例を見てみましょう。 私たちはおそらく、会社や組織内で、Analytics の「頼りになる」人物を名前で知っています。 彼らは、自分にちなんで名付けられたレポートまたはダッシュボード (Mike のレポートまたは Jane のダッシュボード) を持っている人です。 確かに、分析を知っている人は他にもいますが、これらは、最も難しいことを成し遂げ、締め切りを達成する方法を知っているように見える真のチャンピオンです. 問題は、これらの人々が孤立していることです。 多くの場合、プレッシャーがかかると、彼らは誰とも一緒に仕事をしません。 私たちは、この人を失うことになるとは決して考えません。 典型的な「バスにひかれたとしましょう」や、現在の雇用市場の機会を活用する例を使用して、「宝くじに当選しました!」などのポジティブなことを言うのは控えます。この日。
St. Jamesができるまで
月曜日の朝が来て、分析の専門家でチャンピオンの MJ が辞表を提出しました。 MJ は宝くじに当選し、すでに何の心配もなく国を離れています。 MJ を知っているチームと人々は興奮し、嫉妬していますが、仕事は行かなければなりません。 今こそ、MJがしていたことの価値と現実が理解されようとしている時です。 MJ は、分析の最終的な公開と検証を担当しました。 彼らは常に、分析を全員に提供する前に、効率を改善したり、困難な変更を加えたりできるように見えました. 誰もそれがどのように行われたかを本当に気にせず、それが起こったという事実で安全でした.MJはAnalyticsの個人的なロックスターだったので、ある程度の自律性が与えられました. チームが部品、要求、日々の問題、変更要求を拾い始めると、彼らは途方に暮れ、混乱し始めます。 レポート/ダッシュボードが不明な状態で見つかりました。 一部のアセットは週末に更新されませんでした。その理由はわかりません。 人々は何が起こっているのか、いつ修正されるのかと尋ねていますが、MJ が行ったと言った編集が表示されず、その理由はわかりません. チームの調子が悪いようです。 それは惨事であり、今では私たちは皆 MJ を憎んでいます。
レッスン
簡単で明白な要点がいくつかあります。
- 個人が単独で作業することを決して許可しないでください。 良さそうに聞こえますが、小規模なアジャイル チームでは、これを実現する時間も人材もありません。 人が行き来し、タスクが多いため、生産性の名の下に分割統治です。
- 全員が知識を共有する必要があります。 これも良さそうですが、適切な相手と共有していますか? 宝くじの当選者の多くは同僚であることを忘れないでください。 また、知識共有セッションを行うと、タスクから時間を奪われ、ほとんどの人は、必要なときにのみスキルと知識に投資します。
では、誰もが実装して支持できる真のソリューションとは何でしょうか?
構成管理から始めましょう。 これは、いくつかの同様のトピックの包括的な用語として使用します。
- 変更管理： 構造化された体系的な方法で、ソフトウェア システムの変更を計画、実装、および管理するプロセス。 このプロセスの目的は、既存のシステムへの影響を最小限に抑え、組織に最大限の利益をもたらすように、制御された効率的な方法 (元に戻す機能を備えた) で変更が行われるようにすることです。
- プロジェクト管理： ソフトウェア開発プロジェクトの計画、編成、および管理により、予定どおりに、予算内で、必要な品質基準に従って完了するようにします。 プロジェクトの目標を達成し、スケジュールどおりにソフトウェア製品を提供するために、ソフトウェア開発ライフサイクル全体でリソース、アクティビティ、およびタスクを調整する必要があります。
- 継続的インテグレーションと継続的デリバリー (CI/CD): ソフトウェアの構築、テスト、および展開を自動化するプロセス。 継続的インテグレーションでは、定期的にコードの変更を共有リポジトリにマージし、自動テストを実行して開発プロセスの早い段階でエラーを検出する必要があります。 継続的デリバリー/デプロイメントには、テストおよび検証済みのコード変更を本番環境に自動的にリリースすることが含まれます。これにより、新機能と改善の迅速かつ頻繁なリリースが可能になります。
- バージョン管理： 専用のソフトウェア ツールを使用して、ソース コードやその他のソフトウェア成果物への変更を経時的に管理するプロセス。 これにより、開発者はコードベースで共同作業を行い、変更の完全な履歴を維持し、メインのコードベースに影響を与えることなく新機能を試すことができます。
上記のすべては、優れたソフトウェア開発プラクティスに言及しています。 ビジネスを推進し運営する分析は、意思決定にとってミッション クリティカルであるため、それに劣らず価値があります。 すべての分析アセット (ETL ジョブ、セマンティック定義、メトリクス定義、レポート、ダッシュボード、ストーリーなど) は、設計用の視覚的なインターフェイスを備えた単なるコード スニペットであり、一見マイナーな変更が運用に悪影響を及ぼす可能性があります。
構成管理を使用すると、良好な状態で実行し続けることができます。 アセットはバージョン管理されているため、アセットのライフスパンで何が起こったかを確認でき、誰が何に取り組んでいるか、進捗状況とタイムラインを把握でき、制作が続行されることがわかります。 純粋なプロセスでカバーされていないのは、知識の伝達と、物事がそのようになっている理由の理解です。
すべてのシステム、データベース、および分析ツールには、独自の癖があります。 それらを速くしたり遅くしたりするもの、それらを特定の方法で動作させたり、望ましい結果を生み出したりするもの。 これらは、システム レベルまたはグローバル レベルでの設定、またはアセット デザイン内の設定であり、必要に応じて実行することができます。 問題は、これらのことのほとんどが時間の経過とともに学習され、それらを文書化する場所が常にあるとは限らないことです. アプリケーションの実行方法を制御できなくなったクラウド システムに移行し、可能な限り高速化するためにサプライヤーに依存しているにもかかわらず、探しているものを正確に解き放つために資産内で定義の微調整が続けられています。 この知識は、他の人が利用できるようにすることで、取得および共有する必要があるものです。 この知識は、アセットの文書化の一部として必要であり、バージョン管理と CI/CD のチェックインおよび承認プロセスの不可欠な部分であり、場合によっては、すべきこととすべきでないことを公開する前のチェックリストの一部としても必要です。する。
分析プロセスの近道や欠落を隠すための魔法の答えや AI はありません。 データと分析の流れを維持するチームの規模に関係なく、変更を追跡し、すべての資産をバージョン管理し、開発プロセスを文書化し、知識を取得するのに役立つシステムへの投資は必須です。 事前にプロセスと時間を投資することで、後で分析の健全な状態を維持するために物事を考え出すために無駄な時間を大幅に節約できます。 物事が起こり、MJ やその他の宝くじ当選者のための保険に加入するのが最善です。
