運用と保守および個人的なヒロイズム

個人的なヒロイズムとは何ですか?

Interactive Encyclopediaによると、個人的なヒロイズムには次の解釈があります。

それは、人々の大衆の力に依存するという英雄的な思考と行動を強調するのではなく、特定の社会的課題を達成するための個人の力を強調します。「革命的なヒロイズム」と対比。個人主義を原則とし、社会生活や歴史的活動における個人の役割を強調し、「大衆の力と知恵」を二次的な位置に置きます。

上記の解釈はすべての業界に適用される解釈ですが、運用と保守の分野で個々のヒロイズムをどのように定義するのですか?私の理解は次のとおりです。

問題のあるシステムを維持するために個人の力に依存して、すべてが外の世界に正常であるように見えるようにするには、このプロセスで個人の利益を犠牲にする必要があります。

ここで必要なシステムは定義どおりでした。システムは、サービス、チーム、プロセス、ソフトウェアのいずれか、またはそれらの組み合わせにすることができます。

運用と保守における個人的なヒロイズムのパフォーマンス

システムは、上記で定義されている。操作及びメンテナンスの過程で、システムは、一般にSLA、又はシステムの正常な動作を記述することができるいくつかの他の指標を用いて定義されます。

ただし、実際のシステムは所定のSLAまたは目標を達成できないことが多く、この時点でヒーローが現れ、システムが所定のSLAまたは目標に到達するように最善を尽くします。

通常、ヒーローは次の努力によって流れを変えます:

  • 毎日遅くまで働く

  • あなた自身の週末の時間を取りなさい

5d32c198fe5057034c61d27253dd2a4f.jpeg

具体例

チケットキュー

ヒーローのチームは作業指示システムを担当しています。外の世界に約束されたSLAは24時間処理され、さまざまなチームメンバーが毎週交代で作業します。

ビジネスシステムの急速な発展により、8時間以内に処理できない多くの新しい作業指示が毎日届きます。私たちのヒーローはそれらに対処するために遅くまで働きます。毎日の作業時間は8時間から10時間に増加しました。 、12時間、16時間で、約束されたSLAを確実に達成できます。

サービスSLA

主人公のチームが制作サービスを担当し、サービスのSLAは49秒です。ただし、ソフトウェアアーキテクチャの設計、リリースプロセス、およびサービスの監視設定により、サービスは49秒に達しません。

私たちのヒーローは、約束されたSLAを確実に達成できるように、異常な人間の位置、問題のあるリリースのロールバック、リソース警告の早期検出、問題のあるプログラムの再開などについて、サービスの監視システムを毎日パトロールします。

1c2af5a51d1f99e99f26802d4fc30af9.jpeg

個人的なヒロイズムは良いですか?

この質問への答えは、あなたが見ている立場の種類によって異なります。

  1. 会社の観点から

    短期的には会社にとって有益であり、システムの正常な動作が失敗することはありません。長期的には、会社にとっては良くありません。より深いシステムの問題がカバーされているため、システムが高速で開発されるときに問題が明らかになります。遅かれ早かれ、主人公の個人的なエネルギーは使い果たされ、問題は去ったり移ったりした後に明らかになるでしょう。

  2. チームの他のメンバーの観点から

    短期的には、チームの他のメンバーはプロジェクトに専念する時間が増え、些細な事柄に邪魔されることはありません。これは、多くの些細な事柄がヒーローによって処理されているためです。チームは表面的な現象に混乱し、現在の運用および保守システムがうまく機能していると考えて、投資しません。人手は改善しますが、システムが発達して主人公が去ると問題が露呈します。その時、問題解決には時間と労力がかかり、損失は以前より深刻になります。

    主人公の働き方は、他の人にいつの間にか影響を与え、チームメンバーのより価値のある長期的な影響に関する判断に影響を与え、また、維持されているシステムに対するチームメンバーの期待にも影響を与えます(どのようなシステムが機能しているのか)。 )。新しいメンバーは、システムがこのように機能することを当然のことと思うかもしれません。

  3. ヒーローの視点から

    いわゆる個人的な達成感に加えて、主人公自身は良くありません。システムはヒーローなしでは機能できないと主張するかもしれません。ヒーローは報われ、感謝されるべきです。しかし、問題は、他の人がヒーローによるこれらの取り組みについて知らないことです。多くの場合、これらの取り組みは短命で反復的であり、根本的な問題を解決することはできません。彼らは1人の時間とエネルギーで維持できるレベルにとどまり、テクノロジーによって推進されます。会社でこのような仕事をしても、ヒーローに昇進や昇給はありません。

    さらに恐ろしいのは、時間が経つにつれてシステムが大きく複雑になることです。ヒーローがすべての問題を解決できない場合、それはより多くの時間を費やすだけでなく、ヒーローの自信を損ない、作業効率と創造性を低下させ、最終的には主人公の辞任と異動につながる。

  4. システムの観点から

    主人公の積極的な努力により、システムはうまく機能しているように見えますが、根深い体系的な問題はカバーされています。主人公はシステムの通常の操作の単一のポイントになりますが、他の人は知りません。システムの問題を明らかにすることはできないため、改善はありません。システムがより複雑になると、問題はより深刻な方法で明らかになります。多くの場合、変革はコストの上昇を意味します。

個人的なヒロイズムを回避する方法は?

予期せぬ問題に遭遇したとき、個人的なヒロイズムは一時的に困難を克服するのに役立ちます。しかし、長期的には、正しい期待を確立する必要があります。チームの運用および保守システムは、適切に機能するためにヒーローに依存するべきではありません。

なぜそれが起こるのですか?

先に述べた悪いことがたくさんあるのに、なぜそれが起こるのでしょうか?主な理由は次のとおりです。

  1. 短期修复很容易实现,你知道可以完成。(尤其是受冒名顶替综合征影响)

  2. 修复往往立竿见影,带来的成就感。(治标不治本)

  3. 自认为所做的工作非常重要。(其实缺乏全局观念)

如何避免?

如何在运维中避免个人英雄主义,首先需要团队经理或者技术领导能够意识到这个问题,理解这种思想、行为对个人/团队/系统所带来的巨大负面影响,然后采取行动

1. 思想传达

定期、及时的传达个人英雄主义带来的问题,让团队成员清晰的认识到没有必要忍辱负重的维护不合理的SLA或指标;鼓励团队成员分享所遇到的问题;鼓励团队成员及时向上级反馈问题。

2. 工作安排

根据团队成员反馈的问题,合理制定工作,对系统进行改进,使之不依赖于任何单点就可以达到预期的运行状态。团队成员把时间花在可以对系统产生长远收益的项目上。

这是个很高的要求,因为并不是所有人都能看到一个项目对系统能带来的长期收益,抑或是有些人只关心功能的快速上线,这时候运维经理需要顶住迫切上线的压力,合理安排团队成员的时间,以短期被动换取长期的主动。

3. 合理预期

如果系统的SLA或者指标没法达到,承认这个事实,然后对系统进行改进。

这会使系统短时间内达不到SLA,但是通过投入精力改进系统,修复真正的底层问题,系统会最终恢复而且是恢复到一个长期稳定不需要人额外关注就可以达到SLA的状态。

4. 消除单点

团队负责运维的系统很多时,难免会产生不同团队成员负责不同组件的情况,这时即便没人想成为那个英雄也难免被成为那个英雄。

这时每个组件的负责人,就需要尽力消除自己这个单点:

  • 文档记录组件的架构和功能

  • 提供工具自动化处理尽量多的场景

  • 为手工流程提供检查清单

  • 知识分享

  • 人员互备

结束语

个人英雄主义会使人联想到运维团队就好比救火队员的形象,英雄总是能及时扑灭大火,但是也随时忙于扑灭大火,却没有时间把起火的原因彻底解决从而不用忙着扑火了。

减少运维中的个人英雄主义,其实就是降低甚至消除系统对人的依赖,自治程度越高的系统才可能达到更高的SLA,更快速的发布等等。

リーダーにとって、運用と保守をうまく行うためには、システムが個々のヒロイズムに依存していることを発見し、排除する必要があります。個人にとって、運用と保守で良い仕事をするためには、個人的なヒーローとして行動しないという意識を持っている必要があります。

運用と保守を行っている友人に次の文を伝えます。


職業生活のために社会生活を犠牲にして、後でそれを後悔しないでください。


WeChatパブリックアカウント「cloudify」から:当初は、シリコンバレーの分散システム、データセンターの実稼働環境、およびクラウドコンピューティングのフロンティアに関する実践的な経験と分析研究を共有していました。


おすすめ

転載: blog.51cto.com/14996608/2548437