SPLK-3002 Designing Services

Designing Services Detailed Explanation

1. What Is a Service in ITSI?

Simple Definition

In ITSI, a Service is a logical model of something important that your business or organization depends on.

It can be:

• A business function (like "Online Checkout")

• A technical system (like "Web Application Servers")

• A departmental tool (like "Employee Email")

Each service in ITSI is made up of:

• KPIs (to measure how well it’s performing)

• Thresholds (to detect when performance becomes poor)

• Dependencies (to understand what this service relies on)

Real-World Examples of Services

• “Website Frontend”: The public-facing part of your website

• “Database Cluster”: A group of servers running your main databases

• “Email Service”: Handles sending and receiving corporate emails

• “Inventory Management System”: Used by warehouses to track products

The key idea is that each service in ITSI represents something your users or business cares about.

2. Service Design Considerations

Before you create a service in ITSI, you should think carefully about how to design it. Here’s what to consider:

a. Identify Business-Critical Processes

Ask yourself:

• What are the most important systems or services in our organization?

• What business outcome depends on them?

Example:

If customers can't log in, we lose sales.
Therefore, "Authentication Service" is a high-priority service.

b. Break Down Complex Systems

Don’t try to make one giant service for your whole company. Instead:

• Split systems into smaller, logical pieces

• Make each service represent a focused function

Example:

Instead of one “E-Commerce Platform” service, break it into:

“Homepage”

“Product Search”

“Checkout Process”

“Payment Gateway”

c. Define Meaningful KPIs

Each service should be connected to clear, useful metrics—called KPIs. These KPIs will measure:

• Performance

• Availability

• Errors

• User experience

Think about what “healthy” means for each part of your service.

d. Use Templates for Repeated Patterns

If you have many similar services (like microservices or office branches), use Service Templates.

Benefits:

• Saves time

• Ensures consistency

• Easier to update across all services later

We’ll cover templates more deeply in a later section.

3. Key Elements of a Service

A service is more than just a name. It includes several technical parts:

KPI Base Searches

These are searches written in SPL (Search Processing Language) that define how you get the data for your KPI.

Example:

index=web sourcetype=access_logs status=500 | stats count as error_count

This could be used to create a KPI called “HTTP 500 Error Rate”.

Thresholds

You set thresholds to decide:

• What is Normal?

• What is a Warning?

• When is it Critical?

This way, ITSI knows when to:

• Update the service’s health score

• Create Notable Events

Example:

If error_count is:

0–10 → Normal

11–50 → Warning

50 → Critical

Dependencies

Sometimes, a service depends on other services. This creates a parent-child relationship.

Example:

• “Checkout Service” depends on:

  • “Payment Gateway”

  • “Product Database”

  • “User Profile Service”

If one of the child services is unhealthy, it affects the parent service’s health score.

4. Best Practices for Service Design

a. Avoid Overly Broad Services

Don’t try to include everything in one service.
Keep it focused so it's easier to manage, troubleshoot, and measure.

b. Leverage Templates for Scalability

If you have 10 similar services (e.g., one per region or product), don’t build each from scratch.
Create a template with shared KPIs and thresholds, then apply it to multiple services.

c. Clearly Document Purpose and Scope

When you build a service, include notes on:

• What it does

• What systems it includes

• Who owns it

• Why it’s important

This helps your team manage it over time and makes onboarding easier for new team members.

Summary: What to Remember About Designing Services

• A service in ITSI represents a real business or technical function.

• Good service design starts with identifying what’s important and measurable.

• Each service is made up of KPIs, thresholds, and dependencies.

• Use templates to save time and maintain consistency.

• Keep services clear, focused, and well-documented.

Designing Services (Additional Content)

1. Health Score Calculation (Optional but Recommended)

Why it matters:
While not always explicitly tested, understanding how KPI weighting affects the health score is fundamental to designing meaningful and reliable services.

Suggested Addition:

Each service in ITSI has a health score, which is a numeric value (0–100) reflecting the real-time performance and stability of that service.

This score is calculated based on the combined state of its KPIs, using a weighted scoring system.

• You can assign each KPI a relative importance (e.g., 60%, 30%, 10%)

• These weights control how much each KPI influences the overall score

Example:
A service has three KPIs:

• Availability (weight: 50%)

• Error Rate (weight: 30%)

• Latency (weight: 20%)

If the Availability KPI turns Critical, it will heavily impact the total score, more so than the others.

Tip: You can also choose a worst-state logic (e.g., service becomes Critical if any KPI is Critical), depending on your risk tolerance.

This makes health scoring flexible and business-aligned.

2. Visualizing Services with Glass Tables

Why it matters:
Services don’t just run in the background—they’re often the centerpieces of IT dashboards. Showing how service states appear on Glass Tables helps students build a full-stack mental model.

Suggested Addition:

Services can be visually represented and monitored using Glass Tables in ITSI.

• A Glass Table can include:

  • The current health score of a service

  • KPI widgets (gauges, trend lines)

  • Dynamic color changes based on thresholds

  • Linked drill-downs to Deep Dives or Notable Events

Example Use Case:
A Glass Table for an e-commerce company might display:

• The Frontend Service with a green/yellow/red indicator

• Child services like:

  • “Payment Gateway”

  • “Search API”

  • “Authentication Service”

Each node updates in real time, enabling SREs or NOC teams to identify issues immediately.

Navigation tip: Use the Service Analyzer to view tabular and graphical health score breakdowns, or switch to a Glass Table for an interactive layout.

Summary

• They clarify how services are evaluated numerically, supporting better KPI design and alerting logic

• They emphasize the operational visibility of services, linking backend health to frontend dashboards

• They give context for how different user roles (e.g., IT managers, NOC operators) interact with the service layer in ITSI