エンジニアの職人芸を継承すべし | 外道父の匠
『職人芸』。それは、その人にしかできない、または他より圧倒的な品質・精度・速度で仕事を遂行する技術力、というものが確かにあります。 そのような崇高な技術は、どこから来て、どこへ行くのか。そんな圧倒的ポエム回。 職人芸とは 言い方はなんでも良いのですが、組織には上級的なエンジニアが一定割合いて、おそらくその人にしかできない仕事や、手慣れていて効率的に済ませられる仕事を任せられていることでしょう。 そういうエンジニアはたいてい『職人芸』と呼べそうな技術を修得しています。例えば、高精度な設計・高難度な機能実装・的確なコードレビュー・精密な試験・堅牢な運用などなど。 システム提供を大雑把に工程で分類すると、企画・設計・構築・試験・運用 といったところでしょうか。ちょっと外すと研究などもアリですね。それぞれの工程において、集中的に従事して得る職人芸もあれば、多岐にわたる経験によって生まれる職人芸もあ
外道父が清書した .tmux.conf | 外道父の匠
################################################# # # 外道式tmux設定＆重要操作メモ # # - 操作メモはデフォルトではなく設定変更済みに対する説明 ######### # # メモ # # C- と M- の意味 # C-* ... Ctrl + * # M-* ... Alt + * # bind-key の -r オプション # repeat-timeミリ秒の間、2度目以降はPrefixを入力せず # 連続して上下左右を含む同操作を行うことができる # プレフィックスは Pre と表記 # この設定では Ctrl-z にしてある ######### # # セッション管理 # # 作成 # tmux # 名前付き # tmux new-session -s $SessionName # 一覧 # tmux ls # 削除 #
systemd時代に困らないためのlimits設定 | 外道父の匠
数年前に、こういう記事「ulimitが効かない不安を無くす設定」を書きました。しかし、ディストリビューションのバージョンが上がり、デーモン管理が systemd に変わったことで、インターネットのゴミとなりつつあります。 そのため今回は、その次世代バージョン的な内容ということで、systemd の場合はこうしておけば見えない敵と闘うこともなくなるはずです、というものになります。例によって、抑えきれていないパターンがあったら御免なさいです、押忍。 limits設定で目指す所 復習になりますが、limits の設定で困るのはだいたいこういうパターンでしょう。 作業中ユーザーのシェルのlimits設定が思い通りにならない コンソール／SSHログインしてデーモンを再起動したら、limits設定が戻っていた su/sudoを使ってデーモンを再起動したら同上 デーモンをシステムに自動再起動させたら同上
現代ITインフラの王道をゆくLinuxパッケージ管理の基本構成 | 外道父の匠
RedHat系におけるRPMパッケージを扱うYUM、Debian系におけるDEBパッケージを扱うAPT、これらはサーバー管理において重要なわけですが、絶妙な度合いで、おざなりに扱ってもわりとなんとか運用出来てしまう感があります。そのため今一度、こんな感じが今風のスタンダードじゃないっすかね（ｷﾘｯ という構成を説明してみます。 ぶっちゃけ、たいしたことないネタの集合体なので、タイトルに下駄を履かせました。 そもそもパッケージは必要なのか 言うまでもなく必須です。理由は、インストール物のファイル管理が容易になるのと、インストール時間を短縮できるからです。既存のパッケージでconfigureオプションが物足りない時や、RPMパッケージが存在しない場合は作成することになります。 最近はプロビジョニング・ツールによって全て自動化できるので、超簡素なコンパイルのものはレシピに落とし込んで終わりにした
書籍「たのしいインフラの歩き方」を執筆しました | 外道父の匠
エンジニアになってかれこれ14年目、そのうちの多くをインフラエンジニアとして過ごしてきました。ドリコムが弱小ベンチャーの時代から始まり、上場を経て今に至るわけですが…… そんな私の経験を凝縮したような書籍 『たのしいインフラの歩き方』 を執筆しましたことを、ご報告させていただきます！ 本の概要 タイトルどおり、インフラ周りの歩き方について記したものであるため、これを読めば環境を構築できるとか、深い技術や仕組みを理解できる、というようなザ・技術書といった類の内容ではありません。 では、ここでいう歩き方とはなんぞや？といいますと、起業したての小企業から、数百人規模の大企業に至るまでに、どのような技術的要望があり、どのように解決していくのか、という時間軸や規模感に沿ったインフラのエンジニアリングや、その心構え、ということになります。 対象読者としては、大きくは初～中級者のエンジニアとなっています
新卒インフラエンジニアを育成した話 | 外道父の匠
お久しぶりでございます。諸事情によって半年近くも息を潜めていましたが、また継続的なアウトプットをしていきたいと思います。あうとぷっとあうとぷっと。 昨年からAWSに触り始めて、少しずつ研究して、今年から本番運用を開始できています。なので、そっち方面が多くなりそうなのですが、その一発目として昨年にAWSを軸に新卒インフラエンジニアを育成してみた話を書いてみます。 経緯 ウチでは一般的な新卒採用を行っています。内定が出て、入社後はエンジニアも一定期間の研修を受けて、そして配属されることになっています。 私は稀に、キャリアプランによっては内定した段階の子との面談を組まされるのですが、その時点でインフラエンジニアになるという断固たる決意を持っていて、研修の段階に入っても意志は変わらなかった野郎がいたのでインフラ部隊に入れることにしました。しましたといっても普通は、配属は本人の希望以外に人事部判断や
ulimitが効かない不安を無くす設定 | 外道父の匠
limits.conf に書いても ulimit に効いていない、というのはよくある話です。 ulimit が少なくて困ったことはあっても、多くし過ぎて困ったことはほとんどないでしょうから、ドーンと全条件下でulimit設定を効かせる方法を紹介します。 ulimitが効かない問題 だいたいこんな内容だと思います。 SSHログインだと効かない su すると効かない OS起動時に自動起動したデーモンに効かない 普通はデーモンに効けばよいので、本当に困ったら起動スクリプトに直接書いたりしますが、方法としてはイマイチなのでちょっと工夫をします。 その前に・・・ PAMについて PAMというユーザー認証システムについてはググっていただくとして、よく出てくる /etc/security/limits.conf という設定ファイルは、PAMを通る条件下でしか有効になりません。 ではPAMを通るとはどうい
これからはじめるOpenStackリンク集 | 外道父の匠
潤沢な開発環境でも構築しようかなという目的から、OpenStackに触れ始めました。 システム全体の感覚を掴むのに多少時間がかかりましたが、整備された英語マニュアルと 既に数多くある日本語情報のおかげでかなりスムーズに会得できてるのではないかと思います。 あまりまとまりないですし、Debianよりになっていますが 以下、OpenStackリンク集になります。 目次 公式 概要 構築全般 Open vSwitch Quantum Keystone Glance Cinder Swift Ceph VNC Image Quota その他 公式 OpenStack Open Source Cloud Computing Software 日本OpenStackユーザ会 – Japan OpenStack User Group Japan (JOSUG) openstack.jp 技術文書、プレゼ
原因調査用Linuxコマンド | 外道父の匠
サーバの動作に異常が発生した際に原因を探るためのLinuxコマンドで、自分用のメモです。 全てmanとかググったら出てくるので説明は適当です。思いついたら後で追記していくかもです。 対象はDebian Squeezeになります。 全てパッケージインストールできるもので、パッケージ名は [in packagename] としてあります。 各所よりコメントありがとうございます。 良さ気なコマンドは追記していきます。 ＜追加したコマンド＞ * telnet (+コメント wget, netcat) * arp (+コメント arpwatch) * pstree * fdisk コメントに gdisk * host, dig * watch * reboot
Fluentd Meetup #2 発表資料 | 外道父の匠
このブログやTwitterをご縁に、Fluentd meetup in Japan #2 で登壇させていただくことになり、張り切って発表してきました。 発表資料はアニメーションを多様していたのでSlideShareだとわかりづらいかもですが、アップロードしましたので御覧くださいませ。 内容の補足 いくつか質問を受けて答えたりTwitterで見た点について、資料の補足をしておきます。 Agent -> Collector通信経路について Q. なぜVPNにしなかったのか A. VPNは可用性／負荷分散性の点で弱いため。また、VPNサーバや他にもGatewayなど余計な経路を通ることになり無駄である。Agentの増加に対してボトルネックができない構成にしたかったため。政治的な理由で、ある環境だけVPNをはれないといった場合もあり、総合するとGlobal＋暗号化 が良い落とし所だった。 圧縮／暗
Fluentdの所感 その２ | 外道父の匠
YARNについて書きたい気持ちを抑えて前回の続きです。 まだfluentdをがっつり導入しているわけじゃなく、独自プラグインや構成については改良の余地があるかもなので、まぁ参考程度に見ておいてください。 データフロー APサーバのログ書き込みから、HDFSに書き込むまでの処理内容です。パスとかは適当に書き換えてます。なぜこんなフローなのかは後述。めんどいのでテキストで。 (WEB/AP) ◆ログを固定パスに追記 (ex: date >> /tmp/service_plathome_logtype.log のような) ├─□cronによる強制logrotate (10分～1時間程度おき) │ (Fluentd Agent) ◇IN 改造tailプラグインでログ取得 (pathに*の使用可、basenameをtagにできる) │ ◆OUT copy ├─◆flowcounter (unit h
Fluentdの所感 その１ | 外道父の匠
Agent ログの量やFluentd＆CPUの性能を考えると、負荷的には１サーバ１Agentで十分足りるので、ステータス検知などの監視だけしっかりしておけばOKと考えます。なので例えばWEBサーバに普通に１Agent入れてそれが数百・数千台になることを想定します。 Collector 複数台用意し、Agentからroundrobinで送信することで均一化します。Collectorダウン時や復旧時は、ログのロスト無しにすみやかにroundrobinから外れたり復活することを確認済みです。台数が増えすぎた時の懸念点は、HDFSに対する１ファイルへのAPPEND数が増えることですが、ここまでの試験を見る限りはおそらくかなりの数まで大丈夫ですし、仮にHDFSへの書き込みが問題になる場合はAgent -> Collectorの選択条件や、書き込みファイルパスで工夫すれば大丈夫です。 とはいえ、APP
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
