人気のセキュリティエンジニア、希望者が誤解しがちなこと最近、少しおかしくなりつつもあると感じるセキュリティの求人や採用について述べる。今回はセキュリティエンジニアの希望者が誤解しがちなことを指摘したい。japan.zdnet.comセキュリティの本質とは、システムや情報資産などを攻撃者などの脅威から守ることであり、セキュリティエンジニアとは、それができる技術者だ。そのためには、守るべき対象を詳しく知っている必要がある。つまり、セキュリティエンジニアにとって重要なことは、サイバー攻撃自体に関する知識というより、むしろネットワーク、OS、ミドルウェアのようなシステムプラットフォーム全体に関する知識なのだ。 結論から言えば、セキュリティーエンジニアとは、すなわち「インフラエンジニア」である。インフラ運用をしていれば、セキュリティーは範囲に入る。セキュリティーの担保こそインフラエンジニアの主目的

株式会社サイバーエージェントAI事業本部の2024年度エンジニア新卒研修でシステム運用の基本と戦略に関する講義を行いました。

私個人の障害対応の経験と 一昨日参加したIncident Response Meetup vol.1での学びから 障害対応において大切だと感じていることをまとめる。 障害とは リリース後のシステムにおいてシステムの不具合やユーザーの操作ミスによってユーザー業務に影響が出ているもしくは出る恐れがあるもの。 障害対応の目的 システムを直すことではなく、ユーザー影響の回避・低減・早期回復をすること。 障害対応に対する心構え システムの信頼性の要である 障害への対応の仕方でユーザー影響が大きく変わる いつ発生するかわからないため特定の人が常に障害対応をするということは不可能である 素早く適切に行動するための備えが重要である 役割分担 障害対応では復旧対応、原因調査、ユーザーへの説明、社内調整などたくさんのことをやる必要がある。 またそれぞれの作業の難易度が高いことも多い。 一人の人間にできることは

こんにちは。金谷です。 2021年12月10日に行われました、Jenkins Day Japan 2021に登壇させていただいた報告です。 cloudbees.techmatrix.jp本ブログにご訪問いただきました テクマトリックス株式会社 の方にお声がけいただいたことがきっかけで、登壇、講演させていただくことになりました。 改めまして、貴重な機会をいただき、ありがとうございました。 登壇のために資料作りをしたのですが、 Software Design連載 の中であまり語られていないJenkinsまわりの話をまとめることができたことも良かったと思っています。 発表資料 レポート おまけ (講演で話せなかったこと) ジョブ設計の話とソフトウェア設計の関連性 発表後の質疑応答について 運用周り 今後の話とエンジニア募集について 言及している資料 発表資料 発表資料はこちらです。 モノタロウ

プラットフォームチームでSREをしている id:masayosu です。 プラットフォームチームでは、はてなのサービスの基盤となるサービスを開発・運用しています。 さらに、はてラボ(はてなアンテナ、はてな匿名ダイアリーなど)も担当しています。 これらはAmazon EKS(ElasticKubernetes Service)というマネージドコンテナサービス上で、マルチテナントなクラスタとして運用されています。 EKSは2年前から運用を始め、現在は30近いサービスがクラスタ上で動作しています。 この記事ではEKS周辺の構成と、EKSを維持する運用について紹介します。 EKSクラスタの全体構成 EKS全体の構成は、以下の図のようになっています。 図の登場人物について簡単に説明します。AWS EKSAWSのAmazon EKSは、マネージドなKubernetesサービスです。 Kubern

弊社Slackには、 #salad という社員のサラダの注文を管理運用するチャンネルが存在する。このチャンネルでは主にBROS TOKYOというフィットネスラウンジで月額契約している人を対象としたサラダの注文を管理運用している。 1ヶ月契約して毎日食べ続けると800円弱というお手頃価格で結構ボリュームのあるサラダを頼めて、好きなトッピングを3点選べて、体にも良いのでオススメだ。ちなみに私は契約していない。 今回はこのSlackチャンネルの運用についてお話したいと思う。 注文フローの確立まず運用を開始するにあたって、注文フローを確立しなければならない。そこで以下の内容が確立された。 ・以下のフォーマットで書き込むこと: [注文番号, 受取予定時間, 注文内容] ・12:30までに注文完了すること ・全員が注文を終えた後でランダムで1人が全員のサラダを取りに行く それに伴い、注文フローは初日に

多くの人に見てほしいスライド メルカリのマイクロサービス/Kubernetes運用事例を拝見しました。speakerdeck.com こちら、中身はメルカリにおけるマイクロサービス・Kubernetesの実際の運用状況をまとめた内容になっています。 この内容が欲しかった。 この世の中で、会社のITサービス基盤をKubernetesにてマイクロサービス化できている企業はほとんどいません。言い切ります。まだ仮想マシンのWEB+AP+DBの3層構成のままです。もしくは、AWS Lambraなどサーバレスでマイクロサービス化した事例は多数出てきていますがこれは基盤にKubernetesが使われている可能性はあるにしろ、ユーザーは意識していません。Kubernetesをエンタープライズに適用する。このケースではGCEですが企業としてどのようなオペレーションになるのか、どういう思考錯誤があるのかが

もうだいぶ日が経ってしましたが、1/18(金)に SRE Loungeのイベントに参加してきました!すでに7回目の開催ですが、はじめて参加してきました。 SREチームを部署内で立ち上げてみて半年以上が過ぎ、これまでの活動のまとめ・自分の引き継ぎ(産休のため)・来期の計画/活動方針などを考えるタイミングだったので、他社の取り組みを聞いたり、SREs/SREに興味のある方と交流できたのはとても良かったです。 sre-lounge.connpass.com 個人の感想が多分に入ったレポートに仕上がってしまいました(ノ≧ڡ≦) SRE Loungeとは SRE Lounge は、UZABASE のSRE チームが中心となり、発足した勉強会です。 http://tech.uzabase.com/entry/2018/01/26/200021 もともとは、クローズドで少人数な勉強会運営をしておりました

基本的に自分はタスクを拾いすぎてしまう傾向にある。それに加えて比較的朝型なこともあり、前職ではエンジニアの中で一番朝早く出社していることも多かった。*1 その結果どうなるかというと、朝出社して見つけた運用上のトラブルは大体自分がとりあえず手を付ける状態になっていた。前日の夜間バッチやその日の早朝に動くバッチがコケて問い合わせが来ているのでそのリカバリをする、前日にデプロイした後レスポンスが高くなってアラートが出ているのでその調査をする、web appがやたらと500系エラーを吐いているのでBugsnagを見る、等々。 出社している以上無視するわけにもいかないというのもあるが、見つけてしまうと放っておけない性格ということもあり最優先でこれらの対応をしてしまっていた。お陰で前職で触っていたproductについてはかなり広範囲の知見があり、その行動がそれなりに社内での評価につながっていたのではな
「バナナはおやつに入るんですか?」という質問をしたことがあるエンジニアは多いと思います。 私も真っ先にそのような質問をした覚えがあります。 で、実際にバナナを持ってくる人がいるかというと、私は見たことがありません。エンジニアって一般人から見ると変な、もしくは下らない質問が大好きな人種なのではないかと思う事があります。エンジニアというよりもプログラマかもしれませんが、全ての事をswitch case文で考えて、条件分岐の白黒をはっきりさせたがってしまうのではないかと思うのです。 以前、マンション営業をする友人に「職業がエンジニアな人がお客さんだと面倒なときがある」と言われた事があります。 最後に契約書を確認する際に、非常に細かいところを確認したがって面倒であるそうです。 (私は細かく確認しない大多数の人の方が間違っているとは思いますが。。。) 細かい話になってくると、例えば受け渡しの前に
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く