序文
システムヘルス検査
なぜシステムヘルスインスペクションを技術管理に入れるのか？これは非常に重要なリンクだと思います。従来の航空、電力、自動車業界では、機器システムの正常な動作を保証するために特定の検査メカニズムが必要です。また、ソフトウェアシステムには、ビジネスの健全な発展を保証するための検査メカニズムも必要です。
事業の継続的な発展と事業量とデータ量の継続的な増加に伴い、システムアーキテクチャの腐食は避けられません。システムの健全性を確保するためには、システムアーキテクチャとパフォーマンスの最適化を継続的に検討する必要があります。
システムの監視とアラームは、システムの問題をある程度見つけることができます。システムのいくつかの隠れた危険は、システムの検査を通じて発見する必要があります。最適化がタイムリーでない場合、極端な状況で障害が発生します。検査の細かさは、週に1回自分自身を検査することをお勧めします。担当するビジネスシステム。
システム検査は、次の点に焦点を当てています。
●システムインジケータ：システムのCPU、負荷、メモリ、ネットワーク、およびディスクに異常な変動があるかどうか、およびリリースによるものか、システム呼び出しの異常かを確認します。
●遅いインターフェース：一般に、rtが3を超えるインターフェースには注意を払う必要があります。極端な同時実行シナリオは、システム全体の雪崩につながる可能性があります。
●低速クエリ：MYSQL低速クエリには特別な注意が必要です。データ量が増えると、低速クエリを最適化する必要があります。
●エラーログ：エラーログを使用して、システム内のいくつかの隠れたバグを見つけ、これらのバグが拡大するのを防ぎ、極端な場合には誤動作につながることさえありません。
技術計画
技術計画は通常、チームのTLの責任です。TLは、技術債務を返済するために、各会計年度の全体的な状況の観点から各四半期の技術最適化計画を検討する必要があります。技術債務にも関心があります。関心が存在するため、技術債務はタイムリーではありません。返済された場合、将来的には非線形の成長を示し、予期しない損失を引き起こします。
ここでの技術計画には、次の点が含まれます。
●アーキテクチャの最適化：構造が不十分で、凝集性が低く、結合が高いコードでは、要件や機能拡張のわずかな変更でも開始できず、変更のコストが書き換えのコストを超える可能性があります。費用。同様に、システム間の結合にも焦点を当てる必要があります。マイクロサービスの原則に従って、システムは単一の責任の原則に従う必要があります。責任が不明確なシステムの場合は、デカップリングと最適化を実行し、いくつかのモジュール式変換、サービス分離、およびパブリックサービスを実行します。概要。
●パフォーマンスの最適化：システムサービスの現在のQPS \ RTに従って、ビジネスボリュームとデータボリュームの会計年度の開発評価に基づいて、システムパフォーマンスのいくつかのアップグレード戦略を事前に計画する必要があります。これには、一部の低速インターフェイスと低速クエリの最適化に焦点が当てられます。
●回復力と信頼性：システムが提供するサービスは、データの一貫性、独立性、および反重攻撃を保証する必要があります。同時に、ヒューズの劣化やさまざまな場所での複数のアクティビティの観点からどのような問題が存在するか、現在のシステムのSLAインジケーターに到達できるかどうかも考慮する必要があります。高可用性、システムの高可用性を確保するために実行する必要のある最適化。
●スケーラビリティ：アプリケーションサービスがステートレスであることが保証されているかどうか。障害が発生した場合にキーノードを迅速に転送および拡張して、障害の拡大を回避できます。
総括する
テクニカルTLはどのような品質を備えている必要がありますか？
まず第一に、テクノロジーがビジネスそのものであり、その商業的価値を反映しなければならない場合を除いて、テクノロジーは結局のところビジネスに役立ちます。多くの企業で、技術の研究開発は本当に他の部門のニーズを達成するためのツールになっています。そのような技術TLは資格がないに違いないと思います。まず第一に、それは事業の発展に影響を与えることはできません。需要提案者は多くの変革を経験します。考えずに需要が渡されない場合、プロセス全体が歪められます。
第二に、最も重要なことは建築設計の能力であり、おそらく管理の能力は第二だと思います。管理能力にとって最も重要なことは、チームを認識する能力だと思います。テクニカルTLのレベルに達すると、最前線から遠く離れることができず、ビジネスの詳細が不明確になる可能性があり、一般的な方向性が明確でなければなりません。非常に繊細な認識がなければ、多くの決定に偏りが生じます。
彼がビジネスアーキテクトでも、チームをより良い方向に向けることができる人でもない場合、彼は最終的に要件の翻訳者になり、製品マネージャーは彼がやりたいことを何でもします。彼は製品の品質と開発のスピードを確保することにもっと責任があり、最終的には非常に些細な人に解体されました。チームが一定の規模に達すると、チームは純粋な需要の実現からチームの運用に移行し、運用には方向性が必要になります。ビジネスアーキテクチャは、運用とデータに基づく包括的な機能です。
技術的側面に関して、技術的TLは、以下の品質を備えている必要があります。
●優れた技術的ビジョン、優れた問題解決能力、およびアーキテクチャ設計能力。
テクニカルTLは、優れた技術的ビジョンを持ち、すべての種類のテクノロジーに習熟している必要はありませんが、すべてに関与して理解し、さまざまな技術分野の開発動向と主流の非主流テクノロジーの適用シナリオを十分に理解している必要があります。どのシナリオでどのテクノロジーを使用するか、どの規模のビジネス開発を行うか、どのような技術的準備を事前に行う必要があるかを事前に把握してください。
製品アーキテクチャの設計は、現在の開発の高効率を保証するだけでなく、将来の製品アーキテクチャの進化のための拡張の余地を残すのに十分な柔軟性を備えている必要があります。
●強力な実践能力と優れた学習能力。
テクニカルTLは自分でコードを書く必要はありませんが、必要に応じていつでも一次コーディング作業に参加できます。テクニカルTLは、最前線の作業から離れたり、武道を手放したり、紙で話したりすることはできません。そうしないと、このようなことが起こった場合、技術的な判断に重大な誤りが生じます。また、テクニカルTLは、非常に優れた学習能力を備えた人物である必要があります。結局のところ、IT業界のテクノロジー更新速度は非常に高速です。迅速に学習する能力がない場合、テクニカルTLで優れた仕事をする資格はありません。
人事管理に加えて、テクニカルTLには、チームのR＆D文化の確立、チームの人材育成と構築、部門間の調整とコミュニケーションなど、他にも多くのことが必要です。そのため、テクニカルTLには、良好なコミュニケーションと管理能力。