Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
(いたみん)プロジェクトでの運用改善について
Search
akatsukinewgrad
August 02, 2021
Programming
0
1.4k
(いたみん)プロジェクトでの運用改善について
akatsukinewgrad
August 02, 2021
Tweet
Share
More Decks by akatsukinewgrad
See All by akatsukinewgrad
2023/1/25_QAテスター meet up!
akatsukinewgrad
0
110
成果発表資料.pdf
akatsukinewgrad
0
1.9k
広大なフィールドを気持ちよく駆け抜けるための技術.pdf
akatsukinewgrad
0
480
正規表現とReDoS.pdf
akatsukinewgrad
0
470
Unityで大量のオブジェクト_を吹き飛ばしたい.pdf
akatsukinewgrad
0
500
新卒2年目が思う1年目の学び.pdf
akatsukinewgrad
0
450
障害訓練の取り組みについて.pdf
akatsukinewgrad
0
580
7分でわかるアカツキゲームス
akatsukinewgrad
0
490
Bitcoinだけでスマートコントラクト.pdf
akatsukinewgrad
1
760
Other Decks in Programming
See All in Programming
Monixと常駐プログラムの勘どころ / Scalaわいわい勉強会 #4
stoneream
0
290
週次リリースを実現するための グローバルアプリ開発
tera_ny
1
110
KubeCon + CloudNativeCon NA 2024 Overviewat Kubernetes Meetup Tokyo #68 / amsy810_k8sjp68
masayaaoyama
0
260
Amazon S3 NYJavaSIG 2024-12-12
sullis
0
110
数十万行のプロジェクトを Scala 2から3に完全移行した
xuwei_k
0
350
PHPUnitしか使ってこなかった 一般PHPerがPestに乗り換えた実録
mashirou1234
0
330
ある日突然あなたが管理しているサーバーにDDoSが来たらどうなるでしょう?知ってるようで何も知らなかったDDoS攻撃と対策 #phpcon.2024
akase244
2
410
命名をリントする
chiroruxx
1
450
Spatial Rendering for Apple Vision Pro
warrenm
0
150
創造的活動から切り拓く新たなキャリア 好きから始めてみる夜勤オペレーターからSREへの転身
yjszk
1
140
技術的負債と向き合うカイゼン活動を1年続けて分かった "持続可能" なプロダクト開発
yuichiro_serita
0
150
rails statsで大解剖 🔍 “B/43流” のRailsの育て方を歴史とともに振り返ります
shoheimitani
2
960
Featured
See All Featured
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Designing Experiences People Love
moore
138
23k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
132
33k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Embracing the Ebb and Flow
colly
84
4.5k
Making the Leap to Tech Lead
cromwellryan
133
9k
The Pragmatic Product Professional
lauravandoore
32
6.3k
StorybookのUI Testing Handbookを読んだ
zakiyama
27
5.4k
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
Into the Great Unknown - MozCon
thekraken
33
1.5k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
32
2.7k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
910
Transcript
プロジェクトの 運用改善について Akatsuki Geek Live Vol.1
名前:伊丹琢人(いたみ たくと) あだ名:いたみん • 役職 ◦ 19卒クライアントエンジニア ◦ 八月のシンデレラナイン
urakataチーム所属 • 趣味 ◦ fpsやアクションのゲームをする ◦ Vtuberの放送を見たり 最近便利家電を揃えててなるべく楽をしようとしてます 自己紹介
urakataチームとは 新機能などユーザーに価値を提供するチームではなく 運用メンバーに対して価値を提供するチームになります。 現在:クライアント1人、サーバー2人の体制 ハチナイの運用メンバーは主に以下の職種の方がいます • プランナー • 検証
• デザイナー
なぜ運用メンバーに価値を提供するのか?
なぜ運用メンバーに価値を提供するのか? • 手作業による工数の増大 • ヒューマンエラーによる不具合 ユーザーへの還元、最終的にプロジェクトの利益に繋がる 解決
どうやって問題を見つけるか? • まずはヒアリングしてみる → そもそも解決できる問題として認識していないこともあるため 色々と引き出す必要がある。 • 運用改善のslackチャンネルを作成・要望シートに記載を促す →
改善の文化形成、ふとした要望も受け入れるようにして 問題の浮上をしやすく。
• 改善仕様のヒアリングを行う。 → その仕様よりも良いことはないか? 実装工数と工数や不具合の削減量でやるやらないを決定していく • ものによって、コンフルを整備したり → 改善したのに使われないままになったり、引き継ぎができないのを防止
問題解決へ
運用改善 1例の紹介 マスターデータの移行を自動化
ハチナイではマスターデータはスプレで管理されていて 各環境毎にシートがあり、環境によってシートを結合して使います マスターデータの移行作業: 概要 develop sandnext sandbox feature
develop sandbox develop feature sandbox feature sandnext sandbox sandnext sandbox sandbox ※これは一部です
今回はここでの改善 マスターデータの移行作業: 概要 develop sandnext sandbox feature develop
sandbox develop feature sandbox feature sandnext sandbox sandnext sandbox sandbox
sandnext: 本番で使うが、まだ出さないデータで出す日付もバラバラ sandbox : 本番で使うデータでここにあるデータを本番やstagingといった環境に反映 します マスターデータの移行作業: 概要 sandnext sandbox
sandnext sandbox sandnext sandbox sandbox
マスターデータの移行作業: 概要 本番で出すにはsandnextからsandboxへ移動させる必要があり 今まで手作業で移動をさせていた。 また全部ではなく基本次回で出るデータのみ sandnext sandbox 手作業
マスターデータの移行作業: 現状の問題把握 • データ不備の発生 • シートが大量にあるため複数人が最大1時間かかる。しかも増えていく • 当時手作業が当たり前という意識の状態だった
不具合発生・必要工数ともに大きい問題 解決しないとマズイ!
マスターデータの移行作業: 解決への実装と仕様 • 言語はプロジェクトに合わせてrubyを選択 • 実行はjenkins上。パラメータに移動対象の日付を指定してポチるだけ! • 実行結果はslack上に通知
マスターデータの移行作業: 移動の判定 • マスターデータの一番右の列に”デプロイ”を追加して日付を指定 • デプロイ列までを移動対象に • 入れ込むデータは元々判断できるようでデプロイ列はそこに含めない 実際にデータ化されるシート
操作するシート 参照
マスターデータの移行作業: 実装の注意 • 100秒あたり100リクエストの制限 → 制限が来たら待機・リトライ処理を追加 • シートごとにリクエストすると重いのでまとめて処理をする → batch_update_valuesやbatch_get_spreadsheet_valuesを使用
運用していくとシートが増えて制限に引っかかるのも sheets apiの制限についてこちらから https://developers.google.com/sheets/api/reference/limits
マスターデータの移行作業: 作業と結果 • デプロイ日を入れて実行 • 実行結果をslackへ 各マスターで移動ができたら成功アイコン表示
マスターデータの移行作業: 改善効果 • 工数 → 2~4人 x 30 ~ 60分
x 2 ~ 3回デプロイ/1ヶ月 = 最大12時間くらい削減 → + 作業は非同期なので本来の作業に集中可能 通知も平均6分ほどで来る • 不具合 → 処理がデータによっては不具合が発生することがある。 行を手動で追加しないといけなかったりとか・・・ とはいえ手作業でほぼ毎回発生していた不具合は削減
• プロジェクトにspineを導入し、anima2dからspineへの移行 • photoshopスクリプトで必要なspineアトラスを出力するもの • iosのテクスチャ圧縮の更新 PVTRC -> ASTC •
実機内デバッグ機能で検証コストの低減 • github actionでチェッカーを入れたり 他運用改善で行ったものの例
• 運用を続けるプロジェクトは運用を改善していくことも重要 運用し続け肥大化したプロジェクトはどこか負担になっている箇所があり 本来注力すべき業務の時間が減って結果として利益に影響が発生します。 機能実装の攻めと改善の守りで攻守兼ね備えたプロジェクトへ • 改善できるのか?を言いやすい環境へ 負担になって辛いけどしょうがない・・から改善できるかも?に繋げるため チームでコミュニケーションを取ってよりよいチームビルディングへ
まとめ
• iosのPVTRC -> ASTCへの移行 元々PVTRCは縦横ともにサイズが2の累乗だけ対応なので いくつか圧縮されていなかった。-> アセットバンドルの サイズ増大
ASTCに関してはそこが緩和されており置き換えてサイズ削減へ ただしiphone6以降が対応 • anima2dからspineへの移行はアニメーション周りの方からの要望 業界的にspineのほうが扱える方が多くやりやすいというのと、anima2dはもうサポート的にどうなの? という感じだったので移行をしています。 spineはcanvas用とmesh renderer用の2パターンあるので相性が良かった appendix
• 実機内デバッグではSRDebugger経由でアクセスするものが多いです 例えばローディング演出の確認デバッグとか 試合開始のVSが出てるところの確認デバッグとかのキャラ表示チェックとか • photoshopスクリプトはspineのスケルトンデータ1つに対して
キャラのテクスチャを切り替えて表示する形を取っているので 同じ配置になるようphotoshopから自動で配置して出力する機能を作成 appendix