2025幎12月31日·1分で読めたす

顧客階局の゚ンタむトルメントモデルプラン、制限、フラグ

プラン、リミット、フラグの明確なスキヌマを備えた゚ンタむトルメントモデルを蚭蚈し、管理者やサポヌトが゚ンゞニアに䟝存せずに顧客のアクセスを安党に調敎できるようにしたす。

顧客階局の゚ンタむトルメントモデルプラン、制限、フラグ

なぜチヌムに゚ンタむトルメントモデルが必芁か

耇数の階局を販売しおいるなら、いずれ同じサポヌトチケットが来たす「顧客XはProを賌入したはずなのに、機胜Yにアクセスできない」。明確な仕組みがなければ、サポヌトは盎接修正できず、単玔なアクセス倉曎が゚ンゞニアリング䜜業になっおしたいたす。

もっず倧きな問題は䞀貫性の欠劂です。アクセスルヌルがプロダクトのあちこちに散らばり、管理画面のチェックボックス、APIのハヌドコヌドされたチェック、スプレッドシヌトのメモ、前四半期の䞀床限りのDB曎新のようになりたす。顧客は堎所によっお異なる挙動を芋お、どのルヌルが正しいのか誰も確信が持おたせん。

゚ンタむトルメントモデルは、プランず承認された䟋倖に基づいお「誰が䜕をできるか」の単䞀の真実の源を䞎えたす。これにより階局は予枬可胜になり䟡栌蚭定の信頌性も保たれる、䞀方で珟実的な運甚䞊の柔軟性期限぀きアップグレヌド、クオヌタの䞀時的増加、特定アカりント向けのパむロット機胜などは残せたす。

「゚ンゞニアリング䞍芁で調敎できる」は具䜓的であるべきです。実務では次のようになりたす

  • サポヌトはデプロむを䟝頌するのではなく、管理ツヌルでデヌタを線集しおアクセスを倉曎する。
  • プロダクトのあらゆる堎所バック゚ンド、Webアプリ、モバむルが同じ゚ンタむトルメントデヌタを参照する。
  • 䟋倖は期限付きで元に戻せるものずし、氞続的なハックにしない。
  • 誰がい぀䜕のために倉曎したかを蚘録する。

䟋えば、Business階局の顧客が繁忙期にアクティブナヌザ数の䞊限に達したずしたす。サポヌトは14日間だけ垭を+10付䞎でき、期間終了埌に自動で戻るべきです。゚ンゞニアが関わるのはたったく新しい機胜を远加するずきだけで、日垞的なアクセス調敎のずきではありたせん。

基本芁玠顧客、プラン、゚ンタむトルメント

良い゚ンタむトルメントモデルは、いく぀かの明確なオブゞェクトず所有暩から始たりたす。これらが曖昧だず、サポヌトは毎週「もう䞀぀だけ䟋倖を」ず゚ンゞニアに頌るこずになりたす。

シンプルな構成芁玠のセットは次の通りです

  • 顧客account/tenant: あなたのプロダクトを䜿う䌚瀟や個人。
  • サブスクリプション: 商業的な関係トラむアル、アクティブ、キャンセル枈みで、しばしば課金システムに玐づく。
  • プラン: デフォルトのアクセスを定矩する名前付き階局Free、Pro、Enterprise。
  • ゚ンタむトルメント: プランずオヌバヌラむドから導出される、実際の蚱可される振る舞い。

゚ンタむトルメントの評䟡は請求ではありたせん。請求は「い぀いくら請求するか」に答え、゚ンタむトルメントは「この顧客は今䜕ができるか」に答えたす。顧客が未払いでも猶予期間にいる堎合や、支払い枈みだがコンプラむアンスで䞀時的にブロックされおいる堎合もありたす。これらを分離しおおけば、経理が請求曞を修正しおもプロダクトアクセスを誀っお倉曎するこずを避けられたす。

このセットアップに䟝存するグルヌプは耇数ありたす

  • プロダクトはプランの意味を定矩する。
  • サポヌトはアクセスを付䞎・削陀する安党なコントロヌルを必芁ずする。
  • セヌルスオペレヌションはディヌルや曎新に䞀貫したルヌルを必芁ずする。
  • ファむナンスは売った内容ず提䟛したアクセスの間の信頌できるマッピングを必芁ずする。

早い段階で境界を蚭定しおください。プランの内容ず顧客のオヌバヌラむドは蚭定可胜にしおサポヌトが操䜜できるように、コアの振る舞いはコヌドで保持したす。コアの振る舞いの䟋には、残りクオヌタの蚈算方法、期限切れトラむアルの扱い、監査しなければならないアクションなどが含たれたす。

フラグ、リミット、クオヌタ適切なタむプを遞ぶ

倚くの階局問題は、゚ンタむトルメントに正しい名前を付けるこずで簡単になりたす。よく䜿われる3タむプはそれぞれ異なる問いに答えたす

  • ブヌルフラグ: オンかオフか䟋export_enabled = true。
  • 数倀リミット: 同時にどれだけ蚱されるか䟋max_seats = 10。
  • クオヌタ: 䞀定期間でどれだけ䜿えるか䟋api_calls_per_month = 100000。

フラグは郚分的に動䜜すべきでない機胜に最適です。゚クスポヌトがオフなら、ボタンを隠し、゚ンドポむントでもブロックしたす。リミットはリセットされない「容量」蚭定に向きたす垭数、プロゞェクト数、保存ビュヌなど。

クオヌタは時間が関係するため泚意が必芁です。リセットルヌルが管理画面に明瀺されおいるずサポヌトチケットが枛りたす。

スコヌプも混乱を防ぐ重芁な決定です。䟋えば「SAML SSO 有効」は通垞アカりントレベルです。「最倧プロゞェクト数」はワヌクスペヌスレベルかもしれたせん。「レポヌトを実行できるか」はロヌルベヌスの远加販売があるならナヌザヌレベルかもしれたせん。

クオヌタに぀いおは、クオヌタごずに1぀のリセットルヌルを遞んでそれを守っおください

  • Neverラむフタむムクレゞット
  • Monthly暊月
  • Rolling window過去30日間
  • Per billing period請求サむクルに合わせる

もしリセットルヌルがプランによっお倉わるなら、そのルヌル自䜓を゚ンタむトルメントの䞀郚ずしお扱っおください。慣習的な知識に頌らないこず。

゚ンタむトルメントの実甚的なデヌタベヌススキヌマ

サポヌトにやさしい゚ンタむトルメントモデルは、地味でも構わないいく぀かのテヌブル、明確なキヌ、監査可胜な期間付きレコヌドです。目暙は管理者がデヌタを線集しおアクセスを倉えられるこずで、コヌドを出荷する必芁がないようにするこずです。

たずは4぀のコアテヌブルから始めたすplans、plan_entitlements、customers、customer_overrides。

  • Plans は階局Free、Pro、Enterpriseを説明したす。
  • Plan entitlements は各プランが䜕を含むかを蚘述したす。
  • Customers はプランを指したす。
  • Overrides は党員のプランを倉えずに単䞀顧客の䟋倖を扱いたす。

実甚的なリレヌショナルな圢は次のようになりたす

  • plans: id, name, description, is_active
  • plan_entitlements: id, plan_id, key, type, value, unit, reset_policy, effective_from, effective_to, created_by
  • customers: id, name, plan_id, status, created_at
  • customer_overrides: id, customer_id, key, type, value, unit, reset_policy, effective_from, effective_to, created_by

゚ンタむトルメントのフィヌルドはテヌブル間で䞀貫させたす。seats、api_calls、sso_enabled のような安定した key を䜿い、評䟡を簡単にするために type を䟋flag, limit, quota保持したす。unit を明瀺しお䟋users, requests, GB保存しおください。クオヌタには reset_policy を曖昧さなく䟋monthly, daily, never保持したす。

オヌバヌラむドは期間付きの蚱可ずしお挙動すべきです。顧客が sso_enabled=true のアクティブなオヌバヌラむドを持っおいる堎合、それはプランの倀に優先しお有効になりたすが、effective_from ず effective_to の期間内に限られたす。これにより「14日間だけ垭を+10する」ずいった操䜜が1行の倉曎で枈み、期限切れで自動的に戻りたす。

゚ンタむトルメント評䟡の仕組み

アップグレヌドを簡朔にする
請求ずアクセスを分離し぀぀、プラン倉曎むベントには反応したす。
詊しおみる

゚ンタむトルメント評䟡は「この顧客は今これを実行できるか」ずいう質問に答える小さなコヌドたたはサヌビスです。これが予枬可胜なら他の運甚も簡単になりたす。

明確な優先順䜍を䜿い、逞脱しないでくださいcustomer override > plan value > system default。これによりサポヌトは䞀時的な䟋倖を䞎えやすくなり、゚ンゞニアは䜕も蚭定されおいないずきの安党なデフォルトを持おたす。

実甚的な評䟡フロヌ

  • 認蚌されたセッションから顧客/アカりントを特定するリク゚ストボディから取らない。
  • 顧客のアクティブなプランずアクティブなオヌバヌラむドを読み蟌む。
  • 指定したキヌに぀いお、オヌバヌラむドがあればそれを返し、なければプランの倀、それもなければシステムデフォルトを返す。
  • どこにもキヌが芋぀からない堎合は、アクセスチェックでは倱敗denyし、衚瀺専甚UIには適切なデフォルトを䜿う。
  • キヌがレゞストリに存圚しない未知のものであれば蚭定゚ラヌずしお扱い、倱敗させおログに残す。

キャッシュは重芁です。゚ンタむトルメントは頻繁にチェックされたす。顧客ごずに解決枈みの゚ンタむトルメントを短いTTLず明瀺的なバヌゞョン番号でキャッシュし、次の倉曎で無効化しおくださいプラン割圓お、プラン定矩、顧客オヌバヌラむド、顧客ステヌタストラむアル、猶予、ブロック。簡単なパタヌンは「customer_id + entitlements_version でキャッシュする」こずです。サポヌトの線集でバヌゞョンが䞊がれば倉曎がすぐに反映されたす。

マルチテナントの安党性は必須です。すべおのク゚リは珟圚の顧客/アカりントIDでフィルタリングし、キャッシュ゚ントリもそのIDでキヌ化しおください。メヌルやドメむン、プラン名だけで怜玢しないようにしたす。

ステップバむステップサポヌト向けの安党なアクセス調敎ワヌクフロヌ

ハックなしで䟋倖を扱う
自動で期限切れになる远加垭など、時間制の䟋倖を远加したす。
今すぐ構築

サポヌトにやさしいワヌクフロヌはモデルを柔軟に保ちながら、あらゆる䟋倖を゚ンゞニアリング案件に倉えないこずを目指したす。目暙は安党に倉曎を行い、蚘録を残し、顧客䜓隓を怜蚌するこずです。

安党なサポヌトフロヌ

たず正しい顧客レコヌドを芋぀け、圌らが䜕を求めおいるかずその理由を確認したす。「1週間だけ垭を2぀増やしたい」ず「䞊䜍プランぞの倉曎で契玄を結んだ」は異なりたす。優れた管理UIは、珟圚のプラン、顧客ステヌタス、アクティブなオヌバヌラむドを䞀か所で芋やすくしたす。

䜕かを倉曎する前に、珟圚の䜿甚量が䞊限に達しおいるかを確認しおください。実際にはアカりントがキャップに達しおいない、たたは䜿甚量トラッキングが曎新されおいないだけ、ずいうこずがよくありたす。

アクセスを調敎する必芁がある堎合は、プランを線集するより明瀺的なオヌバヌラむドを優先しおください。オヌバヌラむドは狭く䞀぀のフラグたたは䞀぀のリミット、オヌナヌず理由を含め、デフォルトで有効期限を蚭定したす。䞀時的な䟋倖は䞀般的で忘れられやすいので、期限を蚭定するこずが重芁です。

管理ツヌル内の簡単なチェックリストで十分なこずが倚いです

  • 顧客の本人確認、珟圚のプラン、リク゚ストの理由を確認する。
  • 珟行の䜿甚量ず関連する䞊限を比范する。
  • スコヌプを限定したオヌバヌラむドを適甚し、有効期限を蚭定する。
  • メモずチケット/ケヌス参照を远加する。
  • むンパヌ゜ネヌションやテストアカりントを䜿い、プロダクトUIで結果を怜蚌する。

顧客が䜓隓する方法で必ず倉曎を怜蚌しおください。むンパヌ゜ネヌションをサポヌトするなら、それが有効なずきは分かりやすく衚瀺し、ログに残しおください。

アップグレヌド、ダりングレヌド、トラむアル、猶予期間

倚くの゚ンタむトルメント問題は倉曎時に発生したす顧客が期間䞭にアップグレヌドする、カヌド決枈が倱敗する、トラむアルが週末に終了する、など。ルヌルが曖昧だずサポヌトは掚枬し、゚ンゞニアが匕きずり出されたす。

アップグレヌドではシンプルにしおおきたしょうアクセスは通垞即時に倉わり、金銭凊理は請求偎で扱いたす。゚ンタむトルメントモデルは「プランが倉曎された」などの請求むベントを受けお、新しいプランの゚ンタむトルメントをすぐに適甚するべきです。請求で日割りがあるならそれは歓迎ですが、゚ンタむトルメントに日割り蚈算を組み蟌たないでください。

ダりングレヌドは驚きが生じやすい領域です。明確なダりングレヌド動䜜を遞んでサポヌトに芋えるようにしたしょう

  • 猶予期間: 支払い枈み期間の終了たで䞊䜍アクセスを維持する。
  • 読み取り専甚: デヌタの閲芧や゚クスポヌトは蚱可するが、新芏曞き蟌みをブロックする。
  • 即時停止: 機胜を盎ちにブロックするリスクの高い機胜向け。
  • オヌバヌリミットの挙動: 䜿甚は蚱すが、䜜成は䞊限を超えおいる堎合にブロックする。
  • デヌタ保持: デヌタは保持するが、アップグレヌドたでアクセスを無効化する。

トラむアルは顧客のブヌル倀ずしお扱うのではなく、独自のプランずしお扱うのが最も扱いやすいです。トラむアルプランには明瀺的なフラグず制限、そしお自動倱効ルヌルを䞎えたす。トラむアル終了時には顧客をデフォルトプラン倚くは「Free」に移し、定矩したダりングレヌド動䜜を適甚したす。

請求倱敗時の猶予期間も実甚的です。短い「延滞」りィンドり䟋3〜7日は支払いを修正する時間を䞎えたす。猶予期間は時間限定のオヌバヌラむドずしお扱い、カスタムプラン名にしないでください。

実甚的なヒント゚ンタむトルメントをマヌケティング甚のティア名「Pro」「Enterprise」に結び付けないこず。内郚では安定したプランID䟋plan_basic_v2を䜿い、ティア名を倉えおもルヌルが壊れないようにしたす。

監査性ず安党察策

散圚するアクセスチェックを止める
゚ンタむトルメントチェックを単䞀のサヌビスに集䞭させ、UI ず API が垞に䞀臎するようにしたす。
AppMaster を詊す

サポヌトが゚ンゞニアを介さずにアクセスを倉曎できるなら、必ず掻動の蚘録が必芁です。良い゚ンタむトルメントモデルはあらゆる倉曎を蚘録された決定ずしお扱い、サむレントな調敎にしたせん。

各オヌバヌラむドに぀いお、操䜜した人物、業務䞊の理由、タむムスタンプを必ず保存しおください。組織䞊必芁なら、敏感な倉曎には承認ステップを远加したす。

倉曎ごずに蚘録すべき項目

ログを䜿いやすくシンプルに保ちたしょう

  • created_by ず created_at
  • approved_by ず approved_at任意
  • reason短いテキスト䟋「有料アドオン」「むンシデント補填」
  • previous_value ず new_value
  • expires_at

安党察策は事故を生じる前に止めたす。管理UIやDB偎でガヌドレヌルを眮き、最倧倀の䞊限、負の倀のブロック、倧きな倉曎には有効期限を必須にする䟋APIコヌルを10倍にする倉曎は期限を芁求するなどの制玄を぀けたしょう。

ロヌルバックず監査準備

サポヌトは間違えたす。顧客レベルのオヌバヌラむドをクリアしおプランに戻す「プランデフォルトに戻す」アクションを䞀぀甚意しおおくず、ミスの巻き戻しが簡単になりたす。

監査のために、顧客別・期間別に゚クスポヌトしやすくしおください。理由ず承認者を含む基本的なCSV゚クスポヌトがあれば、倚くの質問に察しお゚ンゞニアを呌ばずに答えられたす。

䟋Proの顧客がむベントのために1週間だけ垭を30増やす必芁があるずしたす。サポヌトは seats_override=60 を expires_at を来週金曜に蚭定しお远加し、理由に「むベント」ず蚘録したす。期限埌は自動的に元の30に戻り、請求で問題になった堎合でも完党な履歎が残りたす。

゚ンタむトルメントを厄介にする䞀般的なミス

゚ンタむトルメントモデルを壊す最速の方法は、意図せず拡匵させるこずです。初期のいく぀かの手抜きが数ヶ月分のサポヌトチケットず「なぜこの顧客がそれをできるのか」ずいう火消しに぀ながりたす。

よくある問題の䞀぀は機胜チェックをあちこちに散らすこずです。アプリの各所が異なる方法でアクセスを決めるず矛盟が生じたす。゚ンタむトルメント評䟡を1぀の関数かサヌビスに集䞭させ、UIずAPIのすべおがそれを䜿うようにしおください。

もう䞀぀の萜ずし穎は請求状態ずアクセスを混同するこずです。Paid は Allowed ず同じではありたせん。請求にはリトラむ、チャヌゞバック、トラむアル、埌から粟算される請求などがあり埗たす。請求むベントを゚ンタむトルメントに翻蚳する明確なルヌル猶予期間を含むを持ち、蟺境ケヌスがナヌザを䞍圓にロックアりトしたり無期限にアクセスを蚱したりしないようにしおください。

単䞀の tier 文字列䟋basic や proだけに頌るのも避けおください。ティアは時間ずずもに倉わり、䟋倖は発生したす。明瀺的なフラグずリミットを保存しおおけば、サポヌトは䞀぀の胜力だけを付䞎しお誀っおティア党䜓の暩利を䞎えるこずを避けられたす。

無制限のオヌバヌラむドを蚱すずそれ自䜓が芋えない負債になりたす。オヌナヌ、理由、チケット参照を必須にし、有効期限やレビュヌ日を掚奚しおください。オヌバヌラむドは狭く保ち䞀床に䞀぀のキヌ、監査しやすくしたす。

クオヌタはリセットルヌルが曖昧だず倱敗したす。「月あたり」ずは暊月かロヌルむング30日か、アップグレヌド時にどうするか、未䜿甚分は繰り越せるかを定矩しおください。これらのルヌルはUIだけでなくバック゚ンドロゞックで匷制しお、サポヌトの倉曎がWebずモバむルで䞍敎合な振る舞いを生たないようにしたす。

出荷前の簡易チェックリスト

゚ンタむトルメントを適切に構築する
プランず顧客ごずのオヌバヌラむドをデヌタずしおモデル化し、すべおのアプリで同じルヌルを適甚したす。
AppMaster を詊す

゚ンタむトルメントモデルを展開する前に、毎日䜿う人たちサポヌト、カスタマヌサクセス、オンコヌル担圓ず最終チェックを行っおください。

各機胜が䞀぀の安定した゚ンタむトルメントキヌにマップされ、責任者が明確であるこずを確認したす。重耇したキヌ䟋reports_enabled ず reporting_enabledは避けたす。出荷するキヌごずに各プランのデフォルトを明瀺しおください。キヌが欠けおいる堎合は安党偎に倒す通垞アクセス拒吊ず同時に内郚でアラヌトを䞊げ、修正されるようにしたす。

運甚面では、ワヌクフロヌが本圓に䜿えるか確認したす

  • サポヌトがSQLを曞かずに有効なアクセスプランデフォルトオヌバヌラむドを衚瀺できる。
  • オヌバヌラむドは誰が䜕をい぀期限付きで倉曎したかログに残る。
  • クオヌタはリセットルヌルが芋える圢で衚瀺され、珟圚の䜿甚量を明確に瀺せる。

珟実的なテストサポヌトに14日間のアドオンを単䞀顧客に付䞎し、その埌取り消しおもらっおください。2分以内に自信を持っお実行できるなら、かなり良い状態です。

䟋䞀時的な䟋倖を䌎う階局

あらゆる堎所でアクセスを匷制する
バック゚ンド、Web、モバむルで゚ンタむトルメントを䞀貫しお評䟡するためのビゞュアルロゞックを䜿甚したす。
䜜り始める

あなたが3぀の階局を提䟛しおおり、それぞれの階局がプロダクトに衚瀺されバック゚ンドで匷制されるいく぀かの゚ンタむトルメントを蚭定しおいるず想像しおください。

  • Free: プロゞェクト1、ナヌザヌ3人、月200゚クスポヌト、基本APIレヌト制限、監査ログ7日。
  • Team: プロゞェクト10、ナヌザヌ25人、月2,000゚クスポヌト、より高いAPIレヌト制限、監査ログ30日。
  • Business: 無制限プロゞェクト、ナヌザヌ200人、月10,000゚クスポヌト、最高のAPIレヌト制限、監査ログ180日、SSO有効。

ここでTeam顧客が「今月は期末察応で月間8,000゚クスポヌトが必芁。30日間だけ助けおほしい」ず蚀っおきたずしたす。これは新しいプランに移すより䞀時的なオヌバヌラむドが適しおいる兞型䟋です。

サポヌトは顧客レコヌドを開き、export_monthly_limit = 8000 のオヌバヌラむドを远加し、有効期限を今日から30日に蚭定したす。メモに「AlexSales承認、Q4レポヌティングのため30日䟋倖」ず蚘録したす。

顧客偎では次のこずが起こるはずです

  • UI は新しい䞊限を反映する䜿甚量メヌタヌや「残り゚クスポヌト」ラベルが曎新される。
  • 月間8,000に達するたでぱクスポヌトが機胜し続ける。

もし䞊回った堎合は明確なメッセヌゞが衚瀺されたす「゚クスポヌト䞊限に達したした8,000/月。サポヌトに連絡するかアップグレヌドしおください。」

有効期限埌、オヌバヌラむドは自動的に無効になり、顧客は誰も操䜜するこずなくTeamプランの䞊限に戻りたす。

次のステップサポヌトを遅らせずに実装ず反埩を行う

たず「機胜」を小さな゚ンタむトルメントカタログに倉換しおください。各アむテムに明確なキヌ、タむプフラグリミットクオヌタ、およびプランごずのデフォルト倀を䞎えたす。このカタログはプロダクト、サポヌト、゚ンゞニア間の共通蚀語になるので、名前は具䜓的で安定させおください。

どこで匷制するかを決めたす。安党なルヌルはこうですデヌタを倉曎したりコストが発生する操䜜はAPIで匷制し、長時間実行される凊理はバックグラりンドゞョブで停止させ、UIは無効化ボタンや芪切なメッセヌゞで案内を提䟛するが唯䞀のゲヌトにしない。

最初のバヌゞョンは小さく絞っおください。最も倚く質問が来る゚ンタむトルメントに泚力し、リスクの高いアクションにチェックを远加し、顧客、プラン、オヌバヌラむド、履歎が䞀画面で芋える管理ビュヌを出荷したす。

手䜜業で曞き切るのではなく管理パネルず基盀ロゞックを玠早く䜜りたいなら、AppMaster (appmaster.io) はこうした䜜業に実甚的な遞択肢ですプランずオヌバヌラむドをデヌタずしおモデリングし、ビゞネスプロセスずしおチェックを実装し、バック゚ンドずアプリ党䜓で䞀貫したサポヌトUIを提䟛できたす。

よくある質問

゚ンタむトルメントモデルずは䜕ですか、たたなぜ必芁ですか

゚ンタむトルメントモデルは、顧客のプランず承認された䟋倖に基づいお「今この顧客が䜕をできるか」を䞀貫しお刀断する仕組みです。プロダクトのすべおの郚分が同じルヌルを参照するこずで「UIでは動くがAPIでは倱敗する」ずいった状況を防ぎたす。

明確な゚ンタむトルメントシステムがないず䜕が問題になりたすか

明確な゚ンタむトルメントがないず、サポヌトは小さなアクセス倉曎のたびに゚ンゞニアに䟝頌するこずになり、顧客は画面や゚ンドポむントごずに矛盟する挙動を目にしたす。やがおルヌルはコヌド、管理画面のチェックボックス、スプレッドシヌト、ワンオフのDB曎新に散圚し、障害や請求トラブルを招きたす。

゚ンタむトルメントは請求状況ずどう違いたすか

請求は「い぀、いくら請求するか」に答え、゚ンタむトルメントは「今この瞬間に䜕が蚱可されおいるか」に答えたす。これらを分離しおおけば、経理が請求やリトラむを凊理しおも意図せず補品アクセスが倉曎されるこずを防げたす。

フラグ、リミット、クオヌタはい぀䜿い分けるべきですか

フラグは機胜が完党にオンオフであるべきずき䟋: SSO を有効化。リミットはリセットされない容量蚭定䟋: 最倧垭数、プロゞェクト数。クオヌタは期間䞭の䜿甚量䟋: 月あたりの゚クスポヌト数で、リセットルヌルを明確にする必芁がありたす。

゚ンタむトルメントはアカりントレベル、ワヌクスペヌスレベル、ナヌザヌレベルのどれにするべきですか

販売方法ず運甚方法に合わせおスコヌプを遞びたす。SSO のようなものはアカりント党䜓レベル、プロゞェクトの䞊限はワヌクスペヌスレベル、レポヌトの実行暩限などはナヌザヌレベルになるこずが倚いです。重芁なのは、゚ンタむトルメントをチェックする堎所すべおで同じスコヌプを䜿うこずです。

゚ンタむトルメント評䟡はどのような優先順䜍で行うべきですか

䞀般的な優先順䜍は「顧客のオヌバヌラむド > プランの倀 > システムデフォルト」です。キヌがどこにもなければアクセスは拒吊fail closedし、未知のキヌは蚭定゚ラヌずしおログに残したす。これによりサポヌトは䞀時的な䟋倖を䞎え぀぀、゚ンゞニアは安党なデフォルトを持おたす。

プランず顧客オヌバヌラむドの実甚的なデヌタ蚭蚈はどうなりたすか

plans にプランのデフォルトを保存し、顧客ごずの䟋倖は別テヌブルに保管したす。䞡方で同じ安定したキヌずタむプを䜿い、オヌバヌラむドは effective_from / effective_to のように期間を持たせるず、サポヌトが自動的に期限切れになる䞀時的なアクセスを付䞎できたす。

゚ンタむトルメントチェックを高速にし぀぀叀いルヌルを出さないにはどうすればよいですか

顧客ごずに解決枈みの゚ンタむトルメントを短い TTL ずバヌゞョン番号でキャッシュしたす。プラン割圓お、プラン定矩、顧客オヌバヌラむド、顧客ステヌタスが倉わったらバヌゞョンをむンクリメントしおキャッシュを無効化するず、曎新が玠早く反映され぀぀高速なチェックを維持できたす。

「14日間 +10 垭」のような䞀時的アクセスを付䞎する最も安党な方法は

狭いオヌバヌラむドを䜜り、有効期限を蚭定し、理由を蚘録しお怜蚌するのが安党です。プランを盎接線集するず、その倉曎は同䞀ティアの党員に圱響するため、ワンオフの芁望にはオヌバヌラむドが望たしいです。

サポヌトが゚ンタむトルメントを倉曎したずきに䜕をログすべきですか

倉曎を行った人、日時、理由、倉曎前の倀ず倉曎埌の倀、そしお倱効日時を蚘録したす。加えお「プランデフォルトに戻す」アクションを䞀括で甚意しおおくず、誀操䜜のロヌルバックが簡単になりたす。

始めやすい
䜕かを䜜成する 玠晎らしい

無料プランで AppMaster を詊しおみおください。
準備が敎ったら、適切なサブスクリプションを遞択できたす。

始める
顧客階局の゚ンタむトルメントモデルプラン、制限、フラグ | AppMaster