成熟した自動運転保守システムが持つべき機能
以下は、一部の専門家の回答です,非常に価値のある.
クラウドコンピューティングとDevOpsの現在の開発トレンドを組み合わせる，成熟した自動化された運用および保守プラットフォームには、次の機能が含まれている必要があると思います：
1、ハイブリッドクラウドをサポートするCMDB
現在、ますます多くのサーバーがクラウドに転送されています，主流のパブリッククラウド、プライベートクラウドプラットフォームには、比較的完全なリソース管理APIがあります，
これらのAPIは、自動化されたCMDBを構築するための基礎でもあります。。
新世代の自動化された運用および保守プラットフォームは、これらのAPIに基づいてサーバーを自動的に保守および管理できる必要があります、ストレージ、インターネット、負荷分散されたリソース。
APIを介したリソースの操作は、操作ログとして記録する必要があります，フォローアップ業務監査の基礎データとして準備する。
CMDBは決まり文句のように聞こえます，しかし、これは確かにすべての運用および保守ツールのインフラストラクチャです。
オープンソースツールに基づくプラットフォームの運用と保守の最大の問題，さまざまなツール間でCMDBを統合する方法です。
CMDBは統合されていません，これは、サーバーを追加する必要があることを意味します，さまざまな操作および保守ツールで同期する必要がある場合があります，
これはまだ非常に投げています。。。
二、より完全な監視+アプリケーションパフォーマンス分析（APM）
プラットフォームの可用性をサポートできます、サーバーのパフォーマンス、各種サービス（Webサービス、アプリケーションサービス、データベースサービス）パフォーマンスモニタリング。
より良くすることはより深く行くことができるはずです、または相関パフォーマンス分析。
現在、リソースパフォーマンスモニタリングとアプリケーションパフォーマンスモニタリング（APM）は、一般的に市場で混合されています。，確かに中にはたくさんの製品があります
オーバーラップ，両方の側面が関与します。
オープンソースのパフォーマンス監視システムの主流Zabbix、ナギオス，国内のオープンソース監視プラットフォームにはXiaomiOpenFalconがあります，しかし、これらは基本的にのみです
基本的なリソース監視を行うことです（サーバー，ディスク、ネットワークなど）とシンプルなサービスソフトウェアのパフォーマンス監視（ミドルウェア，データベース等）。
市場に出回っているAPMシステムのより重要な機能は、アプリケーションのパフォーマンス分析です。，たとえば、アプリケーションのURLへのアクセス速度を正確に特定できます。，
一部のSQL実行速度の速度，これらは、開発者や運用および保守担当者が問題をすばやく特定するのに非常に役立ちます。。
この分野のAPMビジネスツール，NewReclicは海外でより主流です、Dynatrace，国内のものも遠近法の宝物です、Oneapm、
クラウドに耳を傾ける，また、統合のためのAPIも提供します。
この分野でのAPMのオープンソースツールはピンポイントです（韓国のチームによってオープンソース化されています），zipkin（twitterオープンソース），猫（パブリックコメントオープンソース）。
三、優れたUIを備えたバッチ操作およびメンテナンスツールがあります
比較的速い事業展開の場合，複数のサーバーから，数十台のサーバーに，何百ものサーバーに，一括運用と保守の需要は当然です
生産，上司はまた、より少ない人がより多くの仕事をすることを望んでいます。
多くのオープンソースのバッチ操作および保守ツールもあります，より成熟している，人形など、シェフ、ansible、ソルトスタック。
人形もシェフもルビー製，正直に，市場に出回っているルビーの熟練した手はほとんどありません，Pythonより難しくない。
私は個人的にansibleまたはsaltstackをお勧めします，どちらのシステムもPythonで書かれています，コードの品質とコミュニティの活動はかなり良いです。
Ansibleには公式のWebUIがあります—タワー，しかし、真実を伝えるのは簡単ではありません，そのため、自分たちで使いやすいWEBUIのセットも再作成しています。。
四、一元化されたログ分析ツール
オンラインシステムの最も一般的な問題の場所を特定する方法，ログ分析です。
サーバーの増加に伴い，ログの分析と配置も困難で苦痛な点になっています（想像してみてください），システムに障害が発生した後，数十またはさらには行く
何百ものノードがログをチェックするために上昇しました，それはどれほどイライラするか）。
中国にLogYiという会社があります，ログ分析の運用および保守ツールに特化しています。
ログの洞察もあります，このフィールドも実行します，しかし、製品はまだベータ版のようです。
ログ分析の分野は今やホットスポットです，現在、より多くのオープンソースソリューションがあります，有名なELKStackなど，
Flume + Kafka + Stormのシステムもあります。
上記の2つのスキームは比較的重いです，展開はより複雑です，オンラインで紹介された記事もたくさんあります。
比較的軽量なオープンソースのログ集中型収集ソリューションには、Python製のSentryがあります，彼は、ログ収集フレームワークをさまざまな言語に変換することでロギングを実装しています
一元化されたコレクション，さまざまな主流の開発言語のロギングフレームワークが完全にサポートされています，javalog4jやlogpackなど。
セントリーの公式ウェブサイトはこちら：
衛兵 – JavaScriptの最新のエラーロギングで例外を追跡する, Python, ルビー, Java, およびNode.js
五、継続的インテグレーションおよびリリースツール
この点で統一された需要を持つことは実際には困難です，多くの企業の統合された出版慣行はまったく異なります。
継続的インテグレーション，一般的にジェキンをもっと使う，この点に関してオンラインで紹介された多くの記事もあります。
パッケージを各サーバーに公開する方法，これは、バッチ操作および保守ツールまたはスクリプトを介して実行できます。。
リリースプロセスには多くの詳細が含まれます，バージョンファイルのアップロードを含む、分布、バージョン管理、ロールバックなどの各種操作。
一般的にそれほど複雑ではないプロジェクトの場合，私の好ましいアプローチは、パッケージ化されたファイルをsvnにアップロードすることです。，次に、各サーバーのスクリプトを使用します
公開操作を行うだけです，これは実際にはSVNを使用してファイルのアップロードを完了しています、分布、バージョン管理、ロールバックなどの各種操作。
六、セキュリティ脆弱性スキャンツール
今ややや有名なシステム，さまざまなセキュリティ攻撃に苦しむ。
平均的な企業がフルタイムのセキュリティエンジニアを雇える可能性は低いです。，したがって、運用および保守エンジニアは、いくつかのセキュリティスキャンツールを使用して調査するのが最善です。
独自のシステムの脆弱性。
セキュリティツールについてあまり知りません，この分野のオープンソースツールに精通していない。
以前、Wuyun.comはSaaSベースの欠落したスキャンプラットフォームであるTang DynastyCruiseを立ち上げました，外部の脆弱性スキャンを提供するAPIがあります，しかし、最近アップグレードされています，
一時的に呼び出すことはできません。
個人的に感じる，上記の機能が利用できる場合，基本的に、中小企業の日常の運用・保守作業の高頻度運用のほとんどをカバーしています。。
- コンピュータ室設備データシステム (EMDB)
- コンピュータルームにサーバーとネットワーク機器のさまざまな情報を入力します，機械モデルなど，ハードディスクのサイズ，OSタイプ，所有するアプリケーション，動作状態，コンピューター室名，部屋で，フレーム，場所などのさまざまな情報，これは最も基本的なデータベースです，主な目的は、各マシンに複数の次元から均一にラベルを付けることです。，他のシステムの使用を促進する。
- さまざまなクエリAPIインターフェースを提供する，そして、許可管理の良い仕事をします。目的は、さまざまな上位システムから呼び出せるようにすることです。，一般的にRESTインターフェース，xmlインターフェース。次に、さまざまな言語に基づいて対応するパッケージライブラリを作成します。
- アプリケーション監視システム(Appmonitor)
- 統合されたデータ取得モジュール，機器の操作情報を収集するために使用されます，ディスクIOを含む，ネットワークトラフィック，CPU使用率，ネットワークデバイスのセッション数，PPS。この取得モジュールは、通常、ネットワーク機器のsnmpによって実現できます。，通常、カスタマイズされたエージェントを介してサーバーに実装されます，このエージェントの最も基本的な機能は、サーバーの動作データを収集することです。，最も重要なことは、さまざまなスクリプト言語を実行し、スクリプト言語を介してサーバー上でさまざまな操作を実現できることです(構成の変更など，アプリケーションログを分析し、結果を出力します)。
- データの保存と視覚化の監視，データ取得モジュールによって収集されるさまざまなデータがたくさんあります，ただし、トランザクション性の要件はありません，HbaseなどのさまざまなNoSQLデータベースを使用できます,達成するカサンドラなど。データの視覚化は、実行できる深くてアプリケーションレベルのことです，一般的に、監視システムでは最も基本的なグラフ表示のみが実現されます，期間ごとに選択して比較する機能を提供します，その他の複雑な視覚化操作は、さまざまなAPIを介して実装されます。
- 監視項目の追加とアラーム通知，監視項目は階層構造です，リスト構造の代わりに。上位ノードの構成は、下位ノードの構成で上書きできます。。ネットワーク機器の場合、監視項目は異なるOIDです。。基盤となるデータ取得モジュールの助けを借りて，サーバーの場合、監視項目は基本的にスクリプトです。標準の監視項目とカスタムの監視項目に分けることができます，標準の監視項目の普遍性を最大化する，CPUを実装する,羊，ディスク，ネットワークおよびその他の情報の監視。カスタマイズされた監視項目は、複数のシステム管理スクリプト言語を使用できます(シェル,python,perl)実現を待つ，スクリプトの出力は特定の仕様を満たすことができます,通常、行構造またはjson文字列を使用します。監視項目ごとに警告を設定,クリティカルアラームしきい値といくつかのアラーム接点，しきい値は通常数値です，スペシャルは文字列にすることができます。しきい値を超える監視項目は、連絡先にアラームを送信します，アラームはSMS経由で行うことができます，郵便物，IMソフトウェアが発行されました。アラーム送信は複合アラームをサポートする必要があります，周波数制御，アラームをオフにします。そうしないと、小さな障害に対して何千ものアラームが発行される可能性があります，アラームはその効果を失います。
- Apiインターフェースを監視する，そして、許可管理の良い仕事をします。実践と目的はEMDBと同じです。オープンモニタリングデータ取得，アラームメッセージの送信，プッシュインターフェイスを構成する。主な目的は、監視システムのデータを外の世界で使用できるようにすることです。，これらのデータに基づいて、よりゴージャスで複雑なデータの視覚化作業を行うことができます，または、よりパーソナライズされた監視とアラームを実行します。二次的な目的は、サーバーの統合された操作をサポートすることです，たとえば、会社のすべてのマシンは、システムソフトウェアのバージョンを一律にアップグレードします。統合操作用のAPIインターフェースは少数の人だけが利用できるようにすることをお勧めします，そして、許可は厳密に管理されています。
- リリースおよびオンライン構成管理システム(ReleaseManager)
- アプリケーションのリリースと依存ライブラリのバージョン管理，アプリケーションのリリースは、運用と保守および開発の間の重要なリンクです，一般リリースシステムはsvnシステムと緊密に統合されます，svnシステムのオンラインアプリケーションのリストがあります，EMDBには各マシンが属するアプリケーションがあります。パブリッシングシステムはこれらのデータを使用します，svnシステムで生成されたアプリケーションパッケージとその依存パッケージをオンラインに公開します，そして、これらのアプリケーションパッケージと依存パッケージのバージョン管理と管理を所有しています，アプリケーションのリリースに問題がある場合は、以前のバージョンにロールバックできます。
- オンライン構成管理，Linuxでのpuppetの機能に似ています，主にアプリケーションサーバー上の主要な構成ファイルのバージョン管理に使用されます，分布，一貫性の維持作業。大規模なアプリケーションは通常、サービスを提供するためにクラスターを形成する複数のサーバーで構成されます，これらのサーバーのアプリケーション構成は一貫している必要があります，ただし、アプリケーションのグレースケール公開操作が行われる場合があります，または、誰かが誤って構成を変更しました。オンライン構成管理システムには、統一された構成変更エントリが必要です，グレースケールリリースのサポートを提供する，同時に、誤った構成変更を修正します。Appmonitorのインターフェイスを使用して操作を実行します。