GNU/Linux >> Linux の 問題 >  >> Linux

DevOpsエンジニアの主な責任

このDevOpsシリーズの記事では、新しい展望を持ったDevOpsを再紹介することから議論を始めました。第2部では、同じことを行いましたが、ソフトウェアリリースライフサイクルに焦点を当てました。

第3部では、ソフトウェアエンジニアとDevOpsエンジニアの役割をポイントごとに表形式で区別しました。

この第4部では、特にDevOpsエンジニアの役割に再び焦点を当て、彼らの主な責任について詳しく説明したいと思います。

始める前に、新しいモデル、特に前に示したシステム開発ライフサイクルとソフトウェアリリースライフサイクルの図をざっと見てみることをお勧めします。

DevOpsエンジニアの本質的な責任を探る

ソフトウェアエンジニアの責任はすでによく知られています。ただし、DevOpsエンジニアの場合、シナリオがどのように変化するかを調査する必要があります。

ソフトウェア展開の計画

ソフトウェアエンジニアが行うようにソフトウェアの設計を計画するのとは異なり、その展開を計画することは、まったく別の責任になる可能性があります。ソフトウェアの予備的な概念に基づいて、開発者はソフトウェアの展開方法に基づいた青写真を作成します。しかし、実際にさまざまなプラットフォームでの展開を計画することは、それが実現するのを見るのに細心の注意を払っているDevOpsエンジニアにとって重要な役割になる可能性があります。

管理コード

コード管理は、本番環境で実行されているソフトウェアにとって重要な側面です。コードの定期的な監査は、実稼働環境で発生する可能性のあるバグを最小限に抑えるのに非常に役立ちます。 DevOpsエンジニアは、アルファレベルのソフトウェアの開始とポストプロダクションから作成された既存のコードの微調整も行います。

展開手順のドキュメント

明確で簡潔なドキュメントがなければ、優れたソフトウェアでさえも役に立たないでしょう。ソフトウェアエンジニアは、ソフトウェアの構築方法と展開方法を文書化します。ただし、DevOpsエンジニアは、展開手順の文書化に専念しています。

ソフトウェアが実稼働環境で使用されるために古くなるほど、展開プロセスを徹底的にチェックすることが重要になります。したがって、文書化は継続的な取り組みであり、コードの改訂と同じくらい重要です。より良いドキュメント=より少ないバグ。ご存知ですか:

ドキュメントテストは、機能しないタイプのソフトウェアテストです。
ソフトウェアの安定したバージョンのみをテストする

ソフトウェアエンジニアとは異なり、DevOpsの役割は、安定したリリースのみに焦点を当てています。これは、これらのバージョンのみが、展開用の本番レベルの環境にとって重要であるためです。最初のADLC(アプリケーション開発ライフサイクル)を終了したソフトウェアは、安定した製品リリースとしての可能性について徹底的にテストする必要があり、専任のDevOpsエンジニアが対応します。

重要な修正を伴うバグレポート(必要な場合)

この部分は、文書化とバグ修正の両方を組み合わせたものです。安定バージョンが本番環境で実行されている場合、このプロセス中に発生するすべてのバグは、ソフトウェアの次の安定リリースのために慎重に修正する必要があります。

一般に、バグ修正は開発者の責任です。ただし、必要に応じて、DevOpsエンジニアが介入して協力し、本質的に重大なバグの修正に対処することもできます。したがって、クリティカルレベルのバグ修正は、この方法で慎重に早めることができます。

また、バグの防止または一時的な回避策(修正されるまで)を文書化することは、ソフトウェアの効率と信頼性にとって非常に有益です。これは、機能、使いやすさ、セキュリティに直接影響します。

実稼働環境での安定したリリースの展開

上記の徹底的なテストに基づいてソフトウェアの信頼性と効率性が確認されると、DevOpsエンジニアによって以前に文書化されたステップバイステップガイドの助けを借りて、最終的に本番環境にデプロイされます。ドキュメントの重要性は、ソフトウェアを本番環境に導入する場合にのみ最もよく理解されます。

デプロイメントの保守と監視

本番環境で実行されているソフトウェアには、継続的なメンテナンスと監視が必要です。 DevOpsエンジニアは、ソフトウェアが最新であり、それらがデプロイされているプラ​​ットフォームも最新であることを確認します。特にこの段階で、将来の保守性を向上させるために本番レベルの動作を記録できます。これには、本番レベルのバグ、新機能の必要性、ユーザーインターフェイスとセキュリティの強化が含まれます。

本番レベルの動作に基づいて設計を再計画する

ソフトウェア展開計画は、その目的を達成するためのツールの展開の予備的な青写真と概念から始まる継続的なプロセスです。最初の安定版リリースがリリースされると、このブループリントは、新しい安定版リリースごとに厳密な改訂が行われます。ソフトウェアの展開手順の改訂は、アプリケーション開発ライフサイクルとシステム開発ライフサイクルの各フェーズから得られたフィードバックに基づいています。

つまり、これはDevOpsエンジニアの役割の重要性を理解するための概要でした。彼らの多様な責任は明らかに彼らを際立たせ、ソフトウェアが寿命に達するまで、そしてそれがなくなるまで、ソフトウェアの継続的な強化を確実にするという彼らの必要性を浮き彫りにします。熱心なDevOpsエンジニアの皆さんに感謝します!

この記事がお役に立てば幸いです。フィードバックや提案として共有する考えが他にもある場合は、下のコメントセクションで行ってください。


Linux
  1. パッケージマネージャーの進化

  2. 各擬似端末(pty)コンポーネント(ソフトウェア、マスター側、スレーブ側)の責任は何ですか?

  3. プライマリと論理パーティション?

  1. Linux用の最高のペイントソフトウェア

  2. トップ10ヘルプデスクサポートチケットソフトウェア

  3. ステガノグラフィ ソフトウェア

  1. RR-ソフトウェアデバッガーの記録と再生

  2. Amazon Glacier に再同期できますか?

  3. Linux のプライマリ パーティションと拡張パーティション