読者です 読者をやめる 読者になる 読者になる

ありがとう。また会おう。

まぁゆるりとやっていきますよと。

2017-02-22 TechLION vol.29

TechLION vol.29
http://techlion.jp/vol29

伊藤直也さんと柄沢聡太郎さん。
この2人のトークが面白くないわけがない、ってことで、早々にエントリーしてたくらい楽しみだったイベント。
期待を裏切らずすごい楽しかった。

いろいろ知見はあったんだけど
後半マネジメントのパートは特に自分の立場と重ねて聞くと、学びが多々あった。

エンジニアであっても、技術はすっげぇできます、でも御社のサービスには興味ありません、では流石に厳しいと。
これは自分が過去の採用面接で取ってきた人と重ね合わせても全く同じ印象。
メルカリはメルカリやってない人は取らないっていってたな。

あと、最後のQ&Aで、評価についての質問がでたところのくだり。

うちの会社もちょうど評価シーズンなので、
その手のイベントをやっているけど
正直なかなか難しいと思っている。
僕の意見も、定量的な評価に寄せすぎるのは危険だと思っていて
定量をクリアするのが目的になってしまう人が少なからずいるから。
ただ、政治的な理由で、どうしてもそういったものを付けなければいけないことはあるので
それはもう「必要悪」と割り切って、あとは定性的な部分を 1on1 でしっかり伝える、しかないんじゃないかなと思っている。

そういえば、最近読んだこの本も面白かった。

人事評価はもういらない

開発現場がアジャイルなら、評価もアジャイルに、てのはわかりやすい話だなと思った。
自分も6社いままで渡り歩いてきて、満足できる評価制度に出会ったことがない。
もしかしたら、この本にあるようなドラスティックな方針転換がそろそろ必要なのかもしれない。

2017-02-03 第2回 セキュリティ共有勉強会

https://intra-security.connpass.com/event/47638/
#intra_security

参加してきました。
いつもどおり、雑多なmemo。

@a_okusan:添付ファイルと暗号化とその意味

メールの添付はやめてクラウド使おうという話。
ただ、世の中には無意味にクラウドアレルギーな人がいるんすよなぁ。。。
そこをどう説得するかが大事な気がする。

@5470v8:CSIRTでなくても回る仕組みづくり(仮題)

とても良い発表だったのだが、
残念ながらご本人の意向であまりこういうところには書かないでほしいようなので。
資料は修正した後に公開する、といっていたような記憶があるので、それに期待。

q09029 : 社会人による衛生開発の実情と情報リスクの共有

なんかすごいことしてる人がいるんだな、とちょっと面食らった。
アマチュア無線は暗号化しちゃいけないだね。

@1samuraiboy:セキュリティ投資の必要性を経営層に納得してもらった方法

セキュリティ意識を高めた3つの方法
 現状を認識してもらう
 事例共有・・・やっぱこれが鉄板だよな。うん。
 経営陣に通じる言葉で話す。
  ビジネス的にどうなるか?を話す。

経営陣が知りたいこと
 うちのセキュリティ対策は大丈夫か。

@usiusi360:脆弱性スキャナVulsを使ってDevSecOpsを実践!

脆弱性チェックの自動化。。。確かに人力はつらい
「見えないことはコントロールできない」
Vuls特徴
 非破壊で安全にスキャン
 日本語レポート、すげぇ大事。
いいな。使ってみたい。
OSC Tokyo 3/10(金)に発表あるとのこと。行きたいけど平日か。。。
仕掛けとしては、yum等のchange logをみてるんだ。なので、負荷はあまり無いとのこと
(sudo権限必要)
 ・・・てことは、手動でソースから入れたやつとかは厳しそう。
メールは1通1通くるらしい、たくさんくるとあれだな。。。
エージェントモードのメリット
 →SSHが不要なこと。SSH直接できないサーバをスキャンするとか。

LT
 (1)インフラ屋がPostfixTLS化で困った話
https://speakerdeck.com/hirofumihida/trouble-with-enabling-tls-on-postfix

 (2)メールフィルタの話
https://docs.google.com/presentation/d/1-UHs3ch6lTv9-Lv8WIhS5-ryyIWnDV7q5Zlb5IxB9Ng/edit#slide=id.p
  サンドボックスのパターンのものを入れた
  質疑応答で聞いたんだけど、やっぱそれでもぬけるケースも多いんだなぁ。 

2017-02-01 MySQL Casual Talks vol.10

https://mysql-casual.connpass.com/event/48473/

参加してきた。
途中でPCのバッテリーが切れてしまって、あまりmemoできなかった。。。

@myfinder
MySQL Casual 運営についての話

Slack運営について
意外と日本語圏外の人もいる

@meijik
MySQLの限界に挑戦する(?!)

超大作なSQLや再起なストアドは限界を見る可能性があると。

@tmtms
MySQL文字コード事情 2017版
http://www.slideshare.net/tmtm/mysql-2017

とても丁寧でわかりやすかった。
それにしても、絵文字の照合問題を考えると
現行は utf8mb4_bin しか選択できないかなぁ。と思った。
utf8mb4_japanese_ci(?)に期待。

あと、クライアントがutf8(not mb4)だと、サーバ側がutf8mb4でも化けるの
よくよく考えりゃそりゃそうなんだが、前ハマったのそれか。。。と既視感があった。

@mita2
MySQL Group Replication - MySQL Casual Talk vol.10
http://www.slideshare.net/satoshimitani71/mysql-group-replication-mysql-casual-talk-vol10

Group Replication良さげだがまだハマりどころがありそう。
もう少しこなれてからかな。

@yoku0825
MySQLアンチパターン
https://yoku0825.blogspot.jp/2017/02/mysql-casual-talks-vol10mysql.html

安定のyokuさんw
今回も楽しませてもらいました。
個人的には、いくつか身に覚えがあるところがあり、gkbr
あと、SQLの可読性問題、これを気にもっと認識されてほしい。

@soudai1025
Webサービスが成長するとロックで苦労する話

soudaiさんの発表も聞いてて楽しい。
ロックはほんとねぇ。。。はまりますよねぇ。。。
ソシャゲやってたときはほんと辛かった。。。

@bizstationcorp
Transactd 高速・高機能なNoSQLプラグイン
http://www.slideshare.net/bizstation/transactd-nosql

知らなかったけど、使い所絞ればパフォーマンスでそう。
RDSでも使えるのかしら。

@bringer1092
Zabbix+group replication
http://www.slideshare.net/bringer1/zabbixgroup-replication-71666508

構成方法がかなりの苦労を感じた。。。
うちのZabbixも。。。そろそろ。。。なぁ。。。

@songmu
Test::mysqldの話

やぱデータも込みでTestしたいってのは完全にAgree。
ただ、そもそもこういうシステムテストする文化が根づいてないとなぁ。。。うーむ。

@i_rethi
Advent Calendarの補足的な話

低レイヤーの話。自分が苦手なところであまり理解できなかった。くぅ。

@kamipo
知って得しない Active Record Issues (MySQL編)
http://kamipo.github.io/talks/20170201-mysqlcasual10/#/title

kamipoさんのコントリビュート力すげぇ。。。

2017-01-30 SRE Tech Talks #2

SRE Tech Talks #2
https://eventdots.jp/event/609456
参加しました。

雑だけど個人memo。

■株式会社メルカリ - SRE 久保達彦 @cubicdaiya
On-call Engineering
https://speakerdeck.com/cubicdaiya/on-call-engineering

SRE 当番制のもろもろの仕組みをエンジニアリングで解決
Slack botにて。勤怠、緊急連絡
PagerDuty APIGoogle Apps Script(スプレッドシート)を活用

質疑応答
・だいたい4,5人で回している
・頻度は1ヶ月に1回も無いくらい(直近は2、3ヶ月前)

サイボウズ株式会社 運用本部・サービス運用部・SRE 深谷敏邦 @toshi_pp
cybozu.com のデータバックアップとリストア、それを活用したリハーサル

SREとバックアップ
 できるだけ安全にやるために
  事前レビュー
  ペアオペレーション
   (第6感で「危ない」と気づく人がいるw)
  バックアップ。あると「安心感」
DM Thin Provisioning(dm-thinp)を活用
バックアップを実際に使うことは99%使わない
アップデートのリハーサルで利用

クックパッド株式会社 インフラストラクチャー部 SRE グループ長 星 北斗 @kani_b
cookpad.com 全 HTTPS 化の軌跡

SRE/情シス/セキュリティ がグループ別れている
SREグループは9名
動機
 セキュリティ、非SSLなログインフォーム(ポップアップダイアログなど)
暗号化の必要性
 保護したい情報は利用者が決められるべき
 前提として通信は暗号化する
 外圧:ATS、Chrome検索エンジンなど
 新技術:HTTP2、ServiceWorker、使い分けの煩雑化→使い分けは事故の元
懸念
 広告・・・HTTPS対応してないものもあった
対応
 とにかくmixedコンテンツへの対応がほぼんど
  CSP使うとエレガントに対応できる
 protocol-relative なURL(//から始まるやつ)に変更
 全社への説明重要 色んな人をまきこむので、コミュニケーション重要
 httpd.confのURL rewriteへの対応
 集計系に影響する可能性あり
 セキュアクッキーとHSTS対応が残ってる
 


■株式会社ミクシィ XFLAG™スタジオ ゲーム開発室 SREグループ 清水 勲 @isaoshimizu
SREグループができてこの半年間やってきたこと
https://speakerdeck.com/isaoshimizu/sregurupugadekitekofalseban-nian-jian-yatutekitakoto

PagerDuty使っている
MySQLチューニング
 innodb_io_capacity
 innodb_spin_wait_delay
OSアップデート
 THP と NUMAの設定要注意


さくらインターネット株式会社 技術本部エンジニア 山田修司 @uzyexe
Arukasの運用事例と、末永くインフラ運用していくためのTips

Arukas:Docker Hostingサービス
利益と信頼関係の両立
「Hope is not a storategy」(SRE本)
PagerDutyを利用
「インフラに強いエンジニアが少ない」「アプリエンジニアの方が多い」
品質のために「入場制限」をかける
可用性における問題:ヒューマンエラー

2017-01-20 第4回実践セキュリティ講座

第4回実践セキュリティ講座
https://yume-ed.connpass.com/event/48872/

参加しました。
セキュリティ、CSIRTといったところを今学んでいるところなのでちょうどよい内容でした。

以下、個人的に気になったワードを、断片的に列挙します。

  • 情報セキュリティは経営マター
  • 会社が抱えるリスク→従業員が抱えるリスク
  • 会社経営におけるリスク・・・発生確率とインパクトの2軸で考える
  • ランサムでお金振り込んで戻ってくる確率は54%という統計がある
    • 身代金を払うことは「反社会的勢力への利益供与」にあたるという解釈をする専門家もいる
  • リスクマネジメント・・・回避、低減、移転、保有 「いくら投資するか」
  • 「守れているか、気づいてないか、たまたま運良く被害にあってないだけ」
  • クレジットカード決済は 透過型よりリンク型が望ましい
  • 従業員の過半数が「情報セキュリティ的にまずい」ことに気づけば自然と報告、改善意識が高まる

2017-01-18 「第44回 脆弱性診断ええんやで」参加

第44回 脆弱性診断ええんやで(^^) OWASP Top 10 の歩き方 一歩目 - 脆弱性診断研究会
https://security-testing.doorkeeper.jp/events/55559

初参加してきました。
最近仕事がセキュリティ絡みのことをやっているので
実践的な内容の勉強会でためになりました。
ツールは実際に手を動かして見るのが大事だなと感じました。
本やWebで見ているだけよりも、感覚として掴めるのは大きいかなと。

今回の勉強会では、Top10の本当に触りだけだったので
もう少し突っ込んだところも聞きたかったなと。次回に期待です。

「足し算の順序」アナタは大丈夫?

この記事は MySQL Casual Advent Calendar 2015 の20日目です。

1ヶ月ほど前ですが、こんな記事がネット上で話題になりましたね。
r25.yahoo.co.jp
togetter.com

個人的には、算数(数学)と国語の授業を取り違えてるんじゃないかな・・・と思ってもやもやします。
数学は抽象化して扱うから、様々な定理・公式が使えるというのに
小学生どあたまの教育でこんな風に教えるんじゃ、ますます算数・数学嫌いを増やすんじゃないかと危惧したりするのですが・・・


ところで。
MySQL(に限った話ではないのですが)では、この「足し算の順序」が重要になる場合があります。

AWS上のMySQLであるRDSでは、タイムゾーンの設定がデフォルトでUTCなので、NOW() 関数を使うと 日本の標準時間(JST)とは9時間ずれた日時が出力されます

※サーバシステム時刻を確認

$ date
Sun Dec 20 12:01:54 JST 2015

※RDSに接続し、NOW()関数を出力

$ mysql -u norii -p -h norii-db.************.ap-northeast-1.rds.amazonaws.com
mysql> SELECT NOW();
+---------------------+
| NOW()               |
+---------------------+
| 2015-12-20 03:02:19 |
+---------------------+
1 row in set (0.01 sec)

なので、これを補正するには、9時間ずらす必要があります*1

mysql> SELECT NOW() + INTERVAL 9 HOUR;
+-------------------------+
| NOW() + INTERVAL 9 HOUR |
+-------------------------+
| 2015-12-20 12:02:29     |
+-------------------------+
1 row in set (0.00 sec)

時に、DBにあるデータに対し、「1ヶ月前」の日時が必要になることがあります。
素朴に現在日時に対する「1ヶ月前」を、上記の要領で求めると

mysql> SELECT NOW() + INTERVAL 9 HOUR - INTERVAL 1 MONTH;
+--------------------------------------------+
| NOW() + INTERVAL 9 HOUR - INTERVAL 1 MONTH |
+--------------------------------------------+
| 2015-11-20 12:02:41                        |
+--------------------------------------------+
1 row in set (0.00 sec)

となります。ここで、「+ INTERVAL 9 HOUR」と「- INTERVAL 1 MONTH」の順序を入れ替えてみます。

mysql> SELECT NOW() - INTERVAL 1 MONTH + INTERVAL 9 HOUR;
+--------------------------------------------+
| NOW() - INTERVAL 1 MONTH + INTERVAL 9 HOUR |
+--------------------------------------------+
| 2015-11-20 12:02:48                        |
+--------------------------------------------+
1 row in set (0.00 sec)

NOW() 関数通してるので秒は実行のタイムラグの分ずれてますが、基本的には同じ日時を指し示しています。

ですが、この計算式は、実行する日時によっては、等値になりません。

たとえば、このSQLを 日本時間の 12月1日 1:00 (UTC では 11月30日 16:00)に実行したとしましょう。
(以下ではNOW()関数ではなく、日時をリテラルで渡しています)

mysql> SELECT '2015-11-30 16:00:00' + INTERVAL 9 HOUR - INTERVAL 1 MONTH;
+------------------------------------------------------------+
| '2015-11-30 16:00:00' + INTERVAL 9 HOUR - INTERVAL 1 MONTH |
+------------------------------------------------------------+
| 2015-11-01 01:00:00                                        |
+------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> SELECT '2015-11-30 16:00:00' - INTERVAL 1 MONTH + INTERVAL 9 HOUR;
+------------------------------------------------------------+
| '2015-11-30 16:00:00' - INTERVAL 1 MONTH + INTERVAL 9 HOUR |
+------------------------------------------------------------+
| 2015-10-31 01:00:00                                        |
+------------------------------------------------------------+
1 row in set (0.00 sec)

と、なんと1日ずれてしまいました。

まぁ考えてみれば当たり前の話で
1ヶ月の日数は、月によって異なるので
上記のSQLで、先に9時間足すと、日付またいで12月1日なるので、その1ヶ月前で11月1日になる
先に1ヶ月減算すると、10月30日になって、そこに9時間足すことになりますが、10月はもう1日ありますから、10月31日になると。

Webアプリケーションで集計組む場合は、プログラム側から日時を渡せばいいですが
ストアドプロシージャでこのような日付周りを扱う場合は、地味にハマるかもしれません。

・・・というか、地味にハマったんでこのエントリ書いたんですけどね(´・ω・`)
なんで素直な順番で書けばなんにも問題ないのにわざわざ順番変えちゃったんだろう。。。

*1:Webアプリケーションから扱う場合は、MySQLのNOW()関数などは使わず、アプリケーション側で日時リテラルを組み立てて渡すべきです