blogこの広告は、90日以上更新していないブログに表示しています。ラストのエントリです。SIerでエンジニアしてます。なった事で幅広いエントリになり、大変勉強になりました。自分としてはネタを出しきったので来年に向けて研鑽していきます。ついて考えている事をまとめます。運用DevOpsは「Develop」=「アイデア→動くソフトウェア」、「Operation」=「インシデント→解決策」という2つの作業を顧客価値向上のためコラボレーションする事です。詳細はALMってなに?をご参照ください。顧客ビジネスの価値向上がゴールではないためSIerへの浸透は時間がかかる気がします。(ちなみに、顧客のビジネス価値向上=対価安くする事、ただ働きと考えている人は頭冷やしてください。考慮しなければ詰むDevOpsの浸透に時間がかかるとは言え運用を考えずに開発すれば、インシデント対応時の調査に不都合が発生し顧客と運用担当者から指摘がきます。指摘によっては自社の評価が悪くなり継続的に仕事を頂けず自社の価値が減ります。「運用のしやすさ」を考慮するのは当然だと思うのですが。開発時になんで運用の事を考えられないか「運用の事を考慮して」は当然の事なのですが出来ていない現場をちょくちょく見ます。定義不足、タイトなスケジュールによる実装対象から外れたなどが直接的な原因ですが、根本は「運用した事がないから」ではないかと考えてます。経験があれば情報収集に困るアプリケーションは作りたくないと考えるはずですが、必要とされるスキルと知識が異なるため開発チームに所属する人は運用経験がない場合がよくあります。そんな人に運用を意識してもらうために幾つかやっていた事をあげてみます。保守開発では運用チームから人を引っ張ってくる機能拡張の時に現在システムを運用している人に設計、テスト設計のレビューをして貰いました。運用時に考慮しなくてはいけない事は設計時に盛り込みますが、システムの癖(顧客がよくチェックする箇所、システムエラーが発生しやすい箇所など)に対応するため運用の方の知識は重要でした。動作確認環境を使い不具合調査シミュレーションログ出力レベルなどの設定を運用時と同一のテスト用環境を構築し、画面間の遷移や機能間の連携のテストを実施しました。そこでシステムエラーなどが発生し、調査しずらい箇所については課題管理してログ出力レベルの見直し等を実施しました。保守運用時も開発時と同じツールを使う開発時、顧客の受入テスト以降は受入テストが運用と考えるとDevOpsの模擬練習のようなもので、顧客のフィードバックをシステムに適切に反映していると思います。ここで学んだリズムがツールによって支えられている場合、例えば、チケット管理でバックログ、バグを管理→バージョン管理にチケット番号を反映してリリース管理となっているとこのツールを使ったよいサイクルはツールがなくなると崩れてしまいます。運用になると顧客環境でチケット管理(インシデント管理)される事が多いためこの旨いサイクルが崩れてしまいます。開発時に使っている環境をそのまま顧客環境で再現するもの手ですが、他社との連携が難しくなります。そのため、ローカルな環境にツールを準備するのはDevOpsを考慮するとよろしくないはずです。私の考えている同じツールを使うという所に見事にマッチしていると思います。クラウド上でデータを管理するため顧客との調整は必要と思いますが、システムの特性によっては可能と思います。ツールを使わなかった、あるシステムのライフサイクル月別アーカイブMessageLeaf参加グループWindows開発者はてなブログをはじめよう!kaji_3さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。