[B! operation] kb84tkhrのブックマーク

kb84tkhr id:kb84tkhr

operationに関するkb84tkhrのブックマーク (8)

GitHub - NII-cloud-operation/Literate-computing-Basics: Literate Computing for Reproducible Infrastructure - Basic Practice
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
kb84tkhr 2019/04/09
operation
リンク
運用自動化、不都合な真実 // Speaker Deck
ssmjp 201712 はたのさん祭での「運用自動化、不都合な真実」の発表資料です。詳細: https://www.opslab.jp/publish/20171212-ssmjp-automation.html (運用設計ラボ合同会社波田野裕一)
kb84tkhr 2019/04/09
operation
リンク
現場の技術を知らずに研究するコンプレックスについて - 人間とウェブの未来
僕は大学時代に研究を続けたかったのだけど、当時アルバイトとして働いていたレンタルサーバー会社の中の取り組みがとても高度に思えて、こういう状況を知らずに研究を続けるのは怖いと思って、大学院に行かずに就職した。そして、3年後になんとか大学院に再び入り直すことができたし、博士課程での研究では随分と会社で学んだ運用技術をネタにした研究をすることができた。これまで、僕は運用技術をネタに研究をやってきたのだが、研究に専念すればするほど、その経過時間だけ新たな運用技術の時代背景や細部も変化していき、それを個人としてうまくキャッチアップして研究につなげていくことが非常に困難であることに数年前から気づき始めた。でも、自分自身はそれを素直に受け入れることができず、どうにか自分の現場の経験があることを武器に研究をすることにこだわっていた。しかし、それも誤魔化しきれない程に、少しずつ少しずつ限界が来ていたし、自
kb84tkhr 2019/03/27
operation

management
リンク
セキュリティを「必要悪」にした犯人は業界自身ではないか？ (1/2)
セキュリティ対策と業務効率や生産性はトレードオフの関係にある。これはまぎれもない事実だ。「だからこそ、双方のバランスが取れるアプローチを模索しよう」――本来ならば、そう受け取られるべき提案だったが、そうはならなかった。 2016年10月20～21日、都内で開催されたセキュリティカンファレンス「CODE BLUE 2016」を締めくくる基調講演「How much security is too much?（セキュリティ対策はどこからが過剰なのか？）」で、カルステン・ノール氏は、セキュリティ業界の人間としてのジレンマを吐露した。イノベーションを阻害しているのはセキュリティ業界かもしれない、と自問業務効率や生産性とのバランスが取れたセキュリティ対策を実施すべきだ――。セキュリティ業界の人間はよく、そのように訴える。だが、現実はそうはなっていない。高度なサイバー攻撃や内部犯行による大型のセキ
kb84tkhr 2018/01/12
何かのときに話の種にしたい

operation

security
リンク
Slack、11月1日に発生した大規模障害の原因は、定期デプロイによるソフトウェア障害が原因
Slackが11月1日に起こした大規模障害は、同社内でデプロイしたソフトウェアが原因だと報告された。全ユーザーがSlackに接続できなくなる障害は2時間以上続き、その後復旧された。その概要と時系列を公開された報告書から追う。オンラインチャットサービスを提供するSlackは、日本時間で11月1日の朝から数時間、全ユーザーが接続できなくなるという大規模な障害を起こしています。 11月4日には、同社のStatusページに障害発生に関するまとめが掲載されました。それによると、障害の原因は同社内で行われていた定期デプロイによってサーバにデプロイされたソフトウェアの障害とのことです。ただしそれがどのような障害であったのか、詳細については現時点では紹介されていません。全ユーザーがSlackに接続できなくなり、復旧に向けサーバ増強障害報告の前半は、概要がまとめられています。後述の詳細によると、同社
kb84tkhr 2017/11/06
operation

cloud
リンク
Microsoft Corporation
kb84tkhr 2017/08/31
development

operation
リンク
Shows - Event & Video Content
Ready to supercharge your Azure game right within GitHub Copilot? Dive into our latest set of videos where we break down six must-try features of GitHub Copilot for Azure. From deploying containers and managing AI models to exploring resources and planning migrations, we've got you covered. Check out the videos to see great examples of how GitHub Copilot for Azure can make your cloud projects smoo
kb84tkhr 2017/07/05
programming

operation
リンク
GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット－ Publickey
果たしてGitLab.comで何が起きたのでしょうか？これまでの経緯をまとめました。スパムによるトラフィックのスパイクからレプリケーションの不調へ GitLab.comは今回のインシデントについての詳細な経過を「GitLab.com Database Incident - 2017/01/31」で公開しています。また、もう少し整理された情報がブログ「GitLab.com Database Incident | GitLab」にも掲載されています。これらのドキュメントを軸に、主なできごとを時系列に見ていきましょう。 1月31日16時（世界協定時。日本時間2月1日午前8時）、YP氏（Yorick Peterse氏と思われる）はPostgreSQLのレプリケーションを設定するためにストレージの論理スナップショットを作成。これがあとで失われたデータを救う幸運につながります。 1月31日21時
kb84tkhr 2017/02/02
computer

operation

trouble
リンク
1