ネットワークのDevOps？ シスコのpyATSとCMLを駆使すればネットワークの可能性は大いに広がる
アプリケーション開発の世界に比べると、ネットワークの構築保守や学習の世界は旧態依然としたイメージが強い。コマンドラインで地味な作業の繰り返し、スキルを習得したいなら実機が必要など。しかし近年ではネットワークエンジニアを取り巻く環境は変化している。プログラマビリティは広がり、DevOpsやCI/CDのような体験もできるようになってきている。NetDevOpsの世界を開く、「pyATS」や「CML」を知っておこう。 ネットワーク環境構築とネットワーク研修の現場が抱える「限界」 ネットワンパートナーズ株式会社の小堀泰樹氏は現在パートナー向けプリセールスをしているが、かつてはネットワークエンジニアでネットワーク環境構築作業に従事していた。「10年も15年も現場ではコマンドライン。手作業に頼って作業している。何も変わらない。このままではよくないと思いました」と述懐する。 ネットワンパートナーズ株式会
財テク - shunirr
前提 shunirr の独自研究による財テクをまとめています shunirr は、そこそこの規模の会社勤務なソフトウェアエンジニア (退職金や企業型 DC は無い) 、独身、副業は特にやっていない 状況の異なる人間は役に立たない情報である可能性が高い フリーランスなどの自営業、スタートアップ企業勤務、あるいは歴史ある大企業勤務、など 結婚してる、家族がいる、など shunirr の思想・価値観によってまとめられているので異なる価値観の人には合わない可能性があります shunirr は全てを実践してはいません 基本的な考え方 資産を増やす方法はいろいろあるけど、税金を減らす方法はあんまり無いので、出来るならやっておきたい 税金は減るとお得だけど、税金が減る額よりも儲かる金融商品があるなら、そっちを買った方がお得 商品の金利や運用益が非課税なものよりも、自分の所得税・住民税から控除される方がお
普通の人が資産運用で 99 点をとる方法とその考え方 - hayato
はじめに 資産運用で 99 点をとる方法とその考え方について説明します。この記事の対象はいわゆる「普通の人」です。 資産運用は趣味ではない。 資産運用を始めてみたいが何をしてよいのかわからない。 資産運用をすでに行っているが毎年ころころと方針を変えてしまっている。 資産運用に無駄に時間ばかり費やしている。 今のところ資産はすべて銀行の普通口座や定期預金にいれている。このまますべて現金でおいておくのも何か損しているみたいでモヤモヤする。だけど難しいことは勉強したくないし時間も使いたくない。 といった人たちです。 記事では最初に結論、すなわち「やるべきこと」を述べます。資産運用で 99 点の投資効率を達成するためにはこの結論部分だけを実行するだけでよいです。 次に、それだけでどうして 99 点といえるのか、その裏付けとなる考え方や理論を中心に説明します。 99 点をとるにあたってこれらの知識を
入社後にAWSアカウントの整理とAWS SSOを導入した話 - トレタ開発者ブログ
こんにちは、2019年7月よりトレタにJOINした @aibou です。 本記事はトレタ Advent Calendar 2019の16日目の記事です。 趣味はNFL観戦とボルダリングです。NFLは今年11月にマイナス気温の屋外で現地観戦してきました。 最近リードクライミングの講習を受けまして、ガシガシと岩を登っております。 さて、今回はAWSアカウントとAWS SSOのお話をしようと思います。 既に社内エンジニアへの共有や社内WikiにAWS SSOの利用マニュアルを残していますが、経緯や変遷について記載していないので、トレタ社員の方にも読み物として読んでいただければなと思っています。 免責事項 本記事を参考に実施したことで発生した金銭・セキュリティ等あらゆる問題について責任を負いかねますので、自己責任のもと実施していただくよう、よろしくお願いいたします。 また、誤り等あればはてブ等でご
【朗報】Youtuber中田敦彦、うっかりまともな資産運用を数十万人に広めてしまう・・・これには金融マンも真っ青 : ライフハックちゃんねる弐式
2019年10月21日 【朗報】Youtuber中田敦彦、うっかりまともな資産運用を数十万人に広めてしまう・・・これには金融マンも真っ青 Tweet 95コメント ｜2019年10月21日 10:00｜貯金・投資｜Editタグ ：中田敦彦 中田敦彦のYoutube大学資産運用編、参照先が山崎元ということで、まともなことしか言わなそうでむしろちょっと退屈だなとか思ってたくらいだけど、あれにすら金融関係者やFPたちがザワついているようで、こりゃテレビじゃできないいい仕事したなと思いを改めた。— Hiro implements Serializable (@hiroakit_roko) October 19, 2019 動画まとめ ■金融業界は、購入者の損益など知った事ではなく手数料を得る為に売っている。 よって営業の話を聞く必要すら全く無い。 ■家は賃貸。新築マンション・一戸建ては×。 なぜな
プロジェクトリスク検知のヒント | DevelopersIO
「プロジェクトのリスクを洗い出しきれていますか？」 この問いに自信を持って「Yes」と即答できる方は以降を確認いただく必要はありません。 「No」もしくは「Yes」と答えるのにちょっと躊躇した方はざっと目を通していただけると、何らかの気づきがあるかもしれません。 ここからは、独立行政法人情報処理推進機構（IPA）が公開している資料を紹介していきたいと思います。 紹介資料 資料名：ITプロジェクトのリスク予防への実践的アプローチ 利用対象者：情報システムの企画、情報システムのプロジェクトマネージャー、PMO、設計者等 特徴：ITプロジェクト目標達成を阻害する事柄をリスクととらえ、リスクとそのリスク発現の要因を中心にすえ、リスクの発現を防ぐために”リスク発現の要因”に対してどのような予防策を打つかその予防策の効果をどのようにとらえるかと”リスク発現の要因”に対してその兆しをどう把握するかの関係
NISAでインデックス積立投資を始める前に考えておくべきこと - ゆとりずむ
こんにちは、らくからちゃです。 先日から、2000万円という金額が独り歩きしていると聞きましたが、一体いまどこにいるのでしょうか？我が家にお越しいただけるのでしたら、熱烈歓迎いたしますので是非！ とまあつまらない小ネタはさておき、世間ではその2000万円を巡って俄に資産運用熱が加熱しているそうです。（やったね金融庁！） www.nikkei.com ネットで話題になった記事を眺めてみても「このビッグウェーブに乗るしか無い！」とばかりに、様々な書き手から色んな記事が上がってくるようになりました。ざっとここ最近で話題になったもので、思い出した範囲を拾ってみてもこの通り。 「年金デモ」やるよりも、「積み立てNISA」やった方が合理的だ。 - sakigake news 「老後2000万円必要」とリスクを煽る新聞社がセットで紹介しない、私がお勧めできるネット証券会社と投資商品 - 斗比主閲子の姑日
Kubernetesに対応した継続的デリバリツール「Razee」、オープンソースでIBMが公開。1万以上のクラスタを25人以下のスタッフで運用した経験を元に
IBMは、同社が1万以上のKubernetesクラスタを25人以下のスタッフで運用してきた経験を元に開発した継続的デリバリツール「Razee」をオープンソースで公開しました。 1万以上のKubernetesクラスタを効率よく運用するには 同社はIBM Cloud上でKubernetesのマネージドサービスを提供しており、これまでに10万以上のKubernetesクラスタを作成し、現在でも6つのリージョンにある35以上のデータセンターで、1万以上のKubernetesクラスタを運用中だとしています。 IBMの説明によると、これだけ大規模になると、Kubernetesを運用管理するためのコントロールプレーンもKubernetesクラスタ上で稼働させており、Kubernetesを運用するためにKubernetesを運用しているという状態。 この規模で、しかも急速に成長中のサービス運用を25人以下
Excel運用からAnsible TowerとGitLab運用に変更してどう変わったかまとめてみた | 日常系エンジニアのTech Blog
Ansible TowerとGitLabを入れてどういう運用を実現したかったかを簡単な例と一緒にまとめてみようと思います。（自分への備忘録含め） ここに書くこと ここでは Ansible Night in Tokyo 2019.04 で話をした中のLinuxサーバ運用編ついてもう少し詳細に書いてみようと思います。 ここで言う運用のイメージは 定常運用 です。 Excel運用課題の振り返り ファイルの管理が「yyyymmdd」などファイルの末尾で管理されていたりしてどれが最新か分かりにくい 手順書の変更履歴が表で管理されていて文字しか書いていなくて before after が分かりにくい レビューシートが手順書ごとに出来ていく、これも日付管理されたり文字で書いてあるだけなので実際にどう修正したのかが残らない 手順書フォーマットは統一されているが、人によって手順の内容がバラバラ 「このファイ
異動のおともにスキルマップ - スタディサプリ Product Team Blog
こんにちは、Web Engineer の @wozaki です。 今回は、スキルマップを私が所属する開発チーム*1に導入した事例をご紹介します。 スキルマップとは、業務で必要なスキル(技術力、業務知識)と、チームメンバーのスキルレベルを一覧にした表です。 スキルマップの例 引用 スキルマップ作成のすすめ | Ryuzee.com 目次 概要 スキルマップ導入の背景 他社の事例とカスタマイズした点 スキルマップ詳細と運用方針 運用結果 まとめ 概要 チームで必要なスキル、メンバーのスキルレベル、志向性が不明だった 個人の志向性を表現できるようにカスタマイズしたスキルマップを導入した 結果 新メンバーにとって、スキル全体が明確になり、チームの役割の理解にも役立った スキル喪失リスクがあるものが明確になり、勉強会などスキル伝承のアクションにつながった 個人の志向性は、スキル伝承時の期待値調整にも
【運用監視ツール比較】ZABBIXからPrometheusへの移行を開始しました - WILLGATE TECH BLOG
概要 運用監視ツールの比較検討をして、ZABBIXからPrometheusへ移行することにしました。 その経緯を書きます。 現状 弊社ではAWSやさくらのクラウド、ConoHaのクラウドなど様々なIaaS/VPSを使って暮らしニスタやMillyなどのサービスを展開しています。 監視対象VM数は170台程度です。 抱えていた課題 重い 監視対象が増えるにつれて重くなってきて、素早く情報を見たい時にストレスになっていました。 ZABBIXのDBはMySQLを使っていましたがパラメータチューニングが必要で、運用に手間がかかっていました。 サポート切れ ZABBIXサーバのバージョンが2.2で、サポート期限の終了が2019年8月と近づいてきていました。 （詳細は公式情報をご覧になってください） スクリーン作成の難しさ ZABBIXはグラフをまとめたものをスクリーンと呼んでいるのですが、スクリーン作
複数のKubernetesクラスタへアプリをまとめてデプロイ、ローリングアップデートなどの新機能を搭載した「Rancher 2.2」が登場
コンテナ管理ツールの「Rancher」を開発するRancher Labsは、複数のKubernetesクラスタをまとめて管理する新機能を搭載した「Rancher 2.2」を発表しました。 RancherはもともとKubnernetesのようなコンテナオーケストレーション機能を備えた、分散環境対応のコンテナ管理ツールでした。独自のコンテナオーケストレーション機能である「Cattle」を搭載し、Kubernetesと機能的に競合する部分がありましたが、昨年リリースされたRancher 2.0からはコンテナオーケストレーション機能としてKubernetesに対応しました。 現在ではKubernetesのデプロイや運用を含む分散環境における総合的なコンテナ運用管理ツールとして開発が進められています。 そしてRancher 2.2ではより高度なKubernetesのクラスタ管理機能として、同一のアプ
｢手順書｣のススメ - Masteries
こんにちは, id:papix です. この記事は, ｢はてなエンジニア Advent Calendar 2018｣の9日目の記事です. qiita.com 昨日は id:wtatsuru さんによる, ｢基盤開発観点からみたはてなのAWS活用のこれまでとこれから｣でした. wtatsuru.hatenadiary.com ｢手順書｣のススメ さて, 早速本題に入っていきましょう. 皆さんは｢手順書｣を書いていますか? 自分はと言うと, 最近そこそこの規模のオペレーションが必要なタスクを担当する機会が多く, その度に手順書を書いて, レビューしてもらってからオペレーションをするようにしています. 例えば, 今年実施した｢はてなが提供するドメインを利用したブログのHTTPS化対応｣のリリースの時は, このような手順書を書いていました: この時は, GitHubのIssueに手順書を用意してい
初公開！ サイボウズの自由すぎる働き方はこんなやり方で管理されていた | サイボウズ式
2018年4月、サイボウズでは「働き方宣言制度」という新たな人事制度が動き始めました。これまでも9種類の柔軟な働き方を認めてきたサイボウズですが、新たな制度はもはやフリースタイル。聞くところでは、社員それぞれがが「働きたい時間と場所を自由に」文章で宣言できるのだそうです。 6月20日にサイボウズ式で公開した記事「自由すぎる……！ サイボウズが最近はじめた新しい「働き方制度」について聞いてみた」では、「人事の運用力がすごい」という反響がありました。 自由に働けるのは素晴らしいこと。しかし一方では、「人事はめちゃくちゃ苦労しているんじゃないか？」「労務管理はどうしてるの？」と勘ぐりたくもなります。社員全員、働き方がバラバラという環境にあって、バックオフィスはさぞかしカオスな状況になってしまっているのではないでしょうか。「みんな自由にやってるけど、人事・労務は毎日深夜残業」とか。 というわけで、
個人で運用するKubernetesクラスタ - k0kubun's blog
Kubernetesの使用感に興味があってaws-workshop-for-kubernetesというのを先週やり、ちょうどEKSがGAになった直後だったのでEKSが試せたのだけど、まあ最初からマネージドだとあまり面白みがないし金もかかるので、個人のVPSで動かしてた奴を全部Kubernetes上で動かすようにしてみている。 まだ本番で運用した知見みたいなのが貯まってるわけではないのだが、公式のドキュメントを中心に読んでいても単に動かし始める段階で結構ハマって時間を消費したので、これから同じようなことをやろうとしている人向けに備忘録を兼ねて使用感や知見をまとめておくことにした。 Kubernetesは今でもalphaやbetaの機能が多く、今後この記事の内容も古くなることが予想されるので、なるべく公式のドキュメントへのリンクを置くのを意識して書いてある。 構成 現時点で、ConoHaで借り
PostgreSQLの“仕様”による、運用者にとって悩み深い脆弱性とは
PostgreSQLの“仕様”による、運用者にとって悩み深い脆弱性とは：OSS脆弱性ウォッチ（6） 連載「OSS脆弱性ウォッチ」では、さまざまなオープンソースソフトウェアの脆弱性に関する情報を取り上げ、解説していく。今回は、2018年3月1日に公開されたPostgreSQLの脆弱性情報（CVE-2018-1058）を取り上げる。 「OSSセキュリティ技術の会」の面和毅です。本連載「OSS脆弱性ウォッチ」では、さまざまなオープンソースソフトウェア（OSS）の脆弱（ぜいじゃく）性に関する情報を取り上げ、解説しています。 今回は、2018年3月1日に公開されたPostgreSQLの脆弱性情報（CVE-2018-1058）を取り上げます。 脆弱性概要 脆弱性の概要は、「A Guide to CVE-2018-1058: Protect Your Search Path」（英語）に詳しく載っています
運用の問い合わせチケットを10分の1に削減した話 - Qiita
Help us understand the problem. What is going on with this article? 会社で働いていると、運用チームからの問い合わせがあると思います。 問い合わせというものは、割り込みに繋がり生産性を下げるのでなるべく減らしていきたいものです。 Redmineで管理されているオープンなチケットを10分の1に削減した話をまとめます。 常時、約50枚ほどオープンなチケットを5枚ほどに減らしました。 問い合わせが多くて辛みを味わっている方の参考になれば。 概要 Web自社サービス タスク管理ツール Redmine 毎日、5枚ほどチケットが増える 運用と開発がそれぞれ20人ほど こんな環境です。 改善のきっかけ うちのチームは、当番制で「問い合わせの窓口」(以下、窓口)となる人を作ります。 窓口の人がチケットを解決したり、有識者にチケットを委譲した
Gitを実践的に使うために参考にすべき記事20選
チームで開発を行うときにGitのスキルは必要不可欠なものとなってきています。以前、Git初心者向けにスライドをまとめたものを紹介しましたが、今回はGit（GitHub）をさらに活用するために参考にしたい記事を紹介します。 この記事は以下のような方におすすめです！ ・ブランチをどのように運用すれば良いのかわからない。 ・コミットメッセージの書き方にいつも悩んでしまう。 ・issueやPull Requestをもっとうまく活用したい。 ・Git�やGitHubに関する便利なテクニックを知りたい。 ・間違ってコミットしてしまったけど対処法がわからない。 今回は、運用編、コミットメッセージ編、issue編、Pull Request編、テクニック編、問題解決編と５つの内容で分類してみました。実践的な読み応えのある記事ばかりなので、ぜひ参考にしてみてください。 運用編 中の人に聞いたGitHub fl
社内ITシステムを構築・運用するのに最重要な3つのポイント - たごもりすメモ
自社で使用するシステムを開発する、とする。 このとき迂闊にやっていると、気付いたら過去に構築したシステムのメンテナンスにばかり時間をとられ、新しいコードがぜんぜん書けていない、という状況に陥ることがある。 こうなると地獄だ。新規の興味深いコードを書くなんてとんでもない、という状態になる。メンテナンスコストを下げるためのコードすら書けなくて永遠に悲惨な撤退戦を繰り返すことになる。絶対に避けなくてはならない。 ということで、自分が心掛けていることをざっと書く。 全く手を入れずに動き続ける状態を最初に作る もちろんシステムというものは生き物なので、ある程度のメンテナンスコストが必要になる。特に会社というものは生き物なのでシステム周囲の環境は常に変化する可能性がある。データ連携している別のシステムの仕様が変われば、当然そのデータを利用する側も対応しなければならない*1。 ということで、システムには
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL InnoDB Cluster を使って運用を手抜きしよう
