タグ付けされた質問 「process」

私は完璧なサーバーを持っていて、とてもきれいで堅実だったので、ペトラと名付けました。あらゆる点で完璧であり、すべてが適切に構成および調整され、完全な100％のサービス記録と753日間の稼働時間がありました。それがうまく動作することを確認するために多くの時間と努力を費やしました。社内の他のサーバーはこれほど優れていませんでした。しかし昨夜、この邪悪なモンスターが理由もなくサーバーをクラッシュさせました。 もちろん、午前2時に通知され、朝までそれを起動して実行し、すべてを構成して調整するのに時間がかかりましたが、以前ほど良くなることはないでしょう。以前の栄光に戻るには数週間かかるかもしれません。今、私の稼働時間は過ぎ去りました。私はほんの3つの9さえ持っておらず、これが私の評判にどう影響するかを知っています。このカオスモンキーは誰ですか？なぜ彼は私のサーバーにそれをしましたか、そしてなぜ彼は私を台無しにしようとしているのですか？

28 amazon-web-services  process  automation  servers  sysadmin 

バリューストリームマッピングについて、またソフトウェアを提供するプロセスを含む製造プロセスのバリューストリームを分析するためにそれをどのように使用できるかについて多くのことを聞きました。ソフトウェア開発および運用チームのコンテキストで正常に配信されるのを見たことはありません。 バリューストリームマッピングとは何ですか？それをソフトウェア配信にどのように適用できますか？

19 terminology  process  project-management  analysis 

ブルックスの法則： 後期ソフトウェアプロジェクトに人員を追加すると、後の作業になります。 彼の本「No Silver Bullet —ソフトウェアエンジニアリングの本質と事故」で、フレデリックブルックスは「神話の男月」の概念を定義しています。 ブルックスの仮定は、複雑なプログラミングプロジェクトを、作業者間のコミュニケーションがなく、タスクとそれを実行する作業者間の複雑な相互関係を確立せずに作業できる個別のタスクに完全に分割できないことです。 1982年以来、私たちは確かに前進し、この問題を緩和するためのさらなる経験を集めてきました。より多くの問題を作成せずにプロジェクトにリソースを追加するために、仕事で正常に適用したソリューションにはどのようなものがありますか。

15 project-management  process  software-engineering 

最近、Amazon S3はus-east-1リージョンで大規模な停止がありました。Ansibleまたは同様のツールでメンテナンスプレイブックを実行しているときに、スペルミスが原因であると思われます。次のように、Ansible-playbookの周りにシェルスクリプトラッパーを配置できます。 #!/bin/bash /usr/bin/ansible-playbook "$@" --list-hosts --list-tasks read -p "Are you sure? (y/n) " answer test "$answer" = "y" || exit 0 exec /usr/bin/ansible-playbook "$@" しかし、安全性を向上させ、会社の重大な停止を引き起こすエラーの可能性を減らすために使用する他のいくつかの方法は何ですか。

12 ansible  process 

大規模な組織で作業するときに、どのようにしてブランチエイジドンの状況を回避しますか？ 私たちは、ソフトウェアの更新ではなく、高/重要なセキュリティパッチとオーダーメイドの機能のみを採用するというアプローチを持つ多くの大規模な金融機関と協力しています。これらの組織は、メジャーアップデートの合間にのみパッチとカスタムリリースを取得します。メジャーアップデートは数年離れている可能性があり、コストが高くつきます。このアプローチにより、私たち（ソフトウェアハウス）は、主要な顧客ごとにコードのブランチを作成します。これには、長期ブランチのすべてのコストと非効率性が伴います。 コミュニティへの私の質問は次のとおりです。 顧客から同様のアップデート承認アプローチを経験しましたか？ このアプローチでの作業を支援するためにどのような提案がありますか？ ソフトウェアの更新を行うための組織のアプローチを変えるためにどのような提案がありますか？

10 release  process  branch 

スクラムやかんばんなどのアジャイルプラクティスは、主にソフトウェア開発用に設計されました。 中断および予定外の作業は、ほとんどのSRE（サイト信頼性エンジニアリング）またはDevOpsチームが行うことの重要なコンポーネントです。Jiraのような追跡システムを使用して作業を管理することは常に役立ちますが、スプリントまたはかんばんはSREチームにとって本当に機能しますか？ 私が見る制約は： 仕事は本質的に非常に動的であり、優先順位は日々変化します。このため、2週間のスプリント期間は非常に積極的で、不要なオーバーヘッドが追加されます。 待機中の人々は問題に別の側面を追加します。時々、複数のチームメンバーがオンコール/事後のタスクに関与する場合があります。 チームには単一の「製品」がないため、一般的な計画プロセスに身を任せません。 タスク間の重複がないため、毎日のスタンドアップ会議はあまり意味がないかもしれません チームは複数のパートナーチームに関連するタスクに取り組んでいるため、複数のJiraプロジェクトにまたがっている可能性があります。スプリントまたはカンバンボードでは1つのJiraプロジェクトしか許可されないため、すべての作業に対応できない場合があります。 私が話し合った多くのSREから聞いたところによると、スプリント計画はそれらに対してまったく機能していません。コミュニティから、スプリントとかんばんの経験について聞いてみたいと思います。 私もこの質問をscrum.orgで行いました： SREチームはスクラムを効果的に使用できますか？

10 process  sre  agile 

私は、devospスタイルのワークフローから従来のdev-then-ops（何と呼ぶか​​わからない）に移行することが良いアイデアかどうかを評価しようとしています。 私たちは、従業員が4000人いる従来のメディア（ソフトウェア以外）などの企業に隠れている5人の小さな部門です。2年前に、部門での生産を大幅に拡大できるソフトウェアの構築を開始しました。私たちはかなり成功しており、より大きな会社が注目を集め始めています。これまでのところ、私たちは、最大10のサービスのAWSマイクロサービスプラットフォームとなったものの設計、開発、デプロイを単独で担当してきました。私たちのチームはDevOpsとして識別しませんが、間違いなく私たちはDevOpsの生活を送っています。各開発者は、コードとそれが実行されるシステムの両方に精通しています。 私たちがまもなく直面する問題の1つは、親会社のIT部門と私たちの間でどのような「効率」が共有されるかです。私たちのプロジェクトオーナーは通常、社内での学習よりもアウトソーシングを好むため、私たちの場合、これらの効率は、可能な限り多くのIT作業を「オフプレート」で行うことを意味します。現在、私たちのチームは、コーディングとインフラストラクチャの経験が70/30％分かれていると思います。IT部門は、IT開発の領域にしっかりと属しており、ソフトウェア開発に目に見えるクロスオーバーはありません。 私たちのプロジェクトオーナー（技術者ではない個人）は、できる限り多くの作業をITチームに引き渡すことで、削減した運用作業の1時間あたりの生産性が最大1：1向上することを期待しています。私はこれについては懐疑的です。私たちの製品はまだプレベータ版です（すでに重要なビジネス資産であるにもかかわらず）。IT部門との限られた経験の中で、ファイルシステムのアクセス許可の変更などの単純なことには通常、大幅な遅延があります。 現在、私の理想的なソリューションは、IT部門が私たちを "採用"し、ITオフィスの標準と要件を確実に満たしながら、私たち自身の仕事を展開し続けることです。それがどれほど現実的かはわかりません。さらに、短期的には追加の運用作業が追加されるため、プロジェクトオーナーが推奨するアプローチとはほぼ逆です。 私たちの状況では、DevOpsアプローチを維持することとITを引き継ぐことの賛成/反対の可能性は何ですか？

9 process  operating-model