CLOSED: AMA with Serhat Can on everything Opsgenie

[Serhat Can]

Update: Our AMA with @Serhat Can is complete! Thank you everyone for taking the time to write your questions and participate, you are the folks that make the community enriching and fun! If you still have questions or thoughts, we'd love to see them in the Opsgenie Collection and we will answer them as soon as possible. 

Thanks again for your participation, it was great chatting with you all! 

Best Wishes, 

Serhat & Kate from the Opsgenie Team 😀

****
Hi there Community! 

My name is Serhat Can and I’m a Technical Evangelist for Atlassian with a focus on Opsgenie, as well as an AWS Hero and DevOps Days Core Organizer. 

I began my career at Opsgenie in Turkey as an engineer building and operating products as part of the Opsgenie Team and now I focus on technical evangelism and helping teams build better on-call and incident response practices. 

On Thursday, July 18 starting at 6 am. PDT I’ll be hosting a real-time AMA to answer your questions about Opsgenie, DevOps, On-call culture, and best practices for Incident Response. 

Here's how it works:

Add your questions below any time before or during the AMA. Be sure to take a look at other community member’s questions and up-vote those that you find interesting.

This AMA is TODAY! Watch the page for answers and feel free to provide follow-up questions and discuss further with other Community members. We'll wrap the event at 8 am PDT, but will be sure to answer any questions we didn't get to.

Some example questions might include “How do I prepare for On-Call?” “What are best practices for incident response in Opsgenie?” “How does my company work to achieve a better uptime statistic?” 

See you there,

Serhat

[Jodi LeBlanc]

I am curious to hear about some interesting user case examples, before and after Opsgenie was implemented.

[Kate Clavet]

Hi! This is a great question, we're currently working on adding various Case Studies to our website, but here are some videos done with customers that are a great way to see some use cases: 
https://youtu.be/EyD-py1hg3s?list=PLqRRY_KP21FulbFb6HinNXmb-jkY_uSwX
https://youtu.be/NjAvpUpvuXo

[Steffen Opel _Utoolity_]

Hi Serhan,

AWS has just superseded CloudWatch Events via the API compatible Amazon EventBridge the other week, with the notable extension of partner event sources to "make it easy for our customers to integrate their own AWS applications with SaaS applications".

Given one of the early partners is PagerDuty, I hope and expect Opsgenie is going to follow suit, can you already share anything about your respective plans?

Cheers,
Steffen

[Serhat Can]

Hey again Steffen!

We are already working on an integration with Amazon EventBridge :)

A side note, EventBridge uses the same underlying structure with CloudWatch Events but it is a completely new product - at least for now.

[Steffen Opel _Utoolity_]

Most excellent, thanks for the confirmation :)

You are right of course that "EventBridge builds upon and extends CloudWatch Events" by using "the same service API and endpoint, and the same underlying service infrastructure". I've just tried to come up with a phrase to quickly convey that users only need to use EventBridge going forward, as per the related FAQs, e.g.:

Q: I currently use Amazon CloudWatch Events and I WANT to try the features of Amazon EventBridge. Do I need to move my Amazon Cloudwatch Events rules and permissions to Amazon EventBridge?

No. Existing Amazon CloudWatch Events users can access their existing default bus, rules, and events in the new Amazon EventBridge console and API or in the Amazon CloudWatch Events console and API.

Q: Are you going to deprecate Amazon CloudWatch Events one day?

No, we are not going to deprecate the API or the service itself. Amazon EventBridge is using the same API, and has added additional features. Over time, the Amazon CloudWatch Events name will be replaced with Amazon EventBridge. [emphasis mine]

I've now replaced 'rebranded' with 'superseded', even though that still doesn't sound 100% accurate.

We are facing that very question within Utoolity's Automation with AWS apps btw. - our existing Put Cloudwatch Events action works out of the box with Amazon EventBridge, and we are currently discussing whether renaming or duplicating is the best way forward usability wise.

[Serhat Can]

Makes sense, thanks for the detailed explanation. I didn't see the "will be replaced" note before.

Looks like even though the recommended way is to use EvenBridge from now on, it will take some time before people start using it. So, I think I'd be more on the duplicating side :)

[Steffen Opel _Utoolity_]

Hi Serhan,

Opsgenie has recently introduced Incident response with AWS Systems Manager by providing AWS Systems Manager Actions. While one of the benefits of AWS Systems Manager Automation is the ease of creating and maintaining SSM Automation documents tailored to custom scenarios, the AWS community also benefits from the many readily available SSM Automation documents provided by AWS, which cover common scenarios on their platform and ease getting started accordingly.

'Incidentally' one of the available automation documents is AWS-CreateJiraIssue, which makes me wonder whether the Opsgenie team is considering a similar collection of readily available SSM Automation documents that cover common scenarios for the Atlassian community?

For example, I'd consider the following Atlassian workflow actions applicable to incident management:

• CreateJiraIssue (covered via AWS-CreateJiraIssue)
• TransitionJiraIssue
• CreateJiraServiceDeskRequest
• ApproveJiraServiceDeskRequest
• ApproveBitbucketPullRequest
• MergeBitbucketPullRequest
• TriggerBambooBuild
• TriggerBambooManualStage

Ah yes, one should also be able to create an endless loop of course ;) (those are more the other side of the coin, making it easy to manage Opsgenie alerts via AWS workflows):

• CreateOpsgenieAlert
• CloseOpsgenieAlert

Of course, I can create any of these myself today, but having the core Atlassian product actions readily available would likewise simplify integrating Atlassian products into AWS automation scenarios.

Cheers,
Steffen

[Serhat Can]

Hi Steffen,

I definetely see your point. I talked with Opsgenie product managers. They are aware of this and they will soon explore more with the AWS team.

Personally, I think these are great suggestions to better integrate with SSM for all relevant Atlassian products.

Thank you!

[Andy - PTC Redundant]

@Serhat Can : Super awesome AMA ! I am a complete Ops Genie n00b... we don't use it in our company (we're way too small and not "busy" enough... however, that will change in the coming year hence my question:

When is the right time during an organisations scale up to introduce Ops Genie?
We're a company of 25 whereby we have 1 person logging in daily to Jira and development teams using it sparingly (1 major project per year).
Due to a major acquisition we're forecasted to grow to 50+ people in the coming year, with 10 complex and challenging projects per year!

[Serhat Can]

@Andy - PTC Redundant , thanks for asking this great question! And it is nice to hear your company is growing :)

Before I answer your question, would you mind telling me how many of you are responsible for running always-on services on production? or in other words, how many people get alerts and try to fix them when something is wrong?

[Andy - PTC Redundant]

Welcome!

We have two project managers, two UX/UI/3D designers, two engineers and thirteen developers that have to respond on alerts. (With devs responding the most)
The PMs are responsible for ensuring smooth running of everything.

[Serhat Can]

First, any company that has a service running all the time needs Opsgenie. Now I assume you have at least one, possibly a dozen soon :)

I think there is one very important factor in deciding when to start using Opsgenie: monitoring.

Do you monitor your services? If not, start there and have some visibility into your infra, services, and connections between services through metrics, logs, and traces. Those visibility endpoints can be used to show if something is going right or wrong. If something is wrong, create an alert. Once you get alerts for problems, you can use Opsgenie.

Opsgenie offers many benefits over simple alerting provided by many monitoring solutions. Most important ones are making alerts actionable, routing them to the right person at the right time, ensuring critical alerts are never missed and gaining insight into areas of success and opportunities for improvement. I won't go into the details because that means going over product features. More info here.

Considering your answer to my earlier question, I'd like to add one important note. It seems like there will be multiple teams with multiple members going on-call. Opsgenie has many features to better support multiple teams and services use-case. Team admins can manage their integrations, on-call schedules, escalations, and services. This gives them the autonomy they need to move faster.

We have customers with a couple of users to thousands of users. Each one has unique use-cases and needs. Opsgenie is flexible enough to support many use-cases natively. We also have almost everything available through APIs that help customers to cover their specific needs.

Hope this answers your question.

Thank you, Serhat.

[Daniel Kim]

Hi Serhan! 

I'm in the early process of setting up on call management for my company so just had a quick question about benefits of utilizing OpsGenie over other vendors. What does OpsGenie do particularly well versus other solutions like Pagerduty or Victorops? 

Many thanks for the help!

[Serhat Can]

Hi Daniel, welcome to the Atlassian Community and thank you for your great question!

We have Opsgenie vs Pagerduty and Opsgenie vs VictorOps pages that I think answers your question from a features perspective. Let me summarize some important differentiators of Opsgenie versus other solutions in the market:

• We have strong integrations (200+) with all the tools you use such as Jira, Slack, DataDog, NewRelic, Nagios, AWS CloudWatch and more. Our integrations framework lets you curate actionable alerts with the right info and route alerts to related teams easily. 
• As expected, we have seamless integration with the rest of the Atlassian tools and we are always improving this experience.
• Opsgenie connects with AWS System Manager or other 3rd party admin tools to automatically execute actions by using dynamically populated or user-defined parameters. This is called "Opsgenie actions" and dramatically reduces the resolution time through automation.
• We can handle alerts differently based on their source, information, or time of day. For example, Opsgenie has the ability to delay alert notifications (useful for ensuring low priority alert are only handled during business hours, and that flapping issues have the needed time to resolve themselves)
• We have greater escalation options and unique features including; alert customization, alert tagging, and grouping.
• We have Opsgenie Edge Connector that gives you the ability to securely connect all on-prem solutions.
• We have Opsgenie Edge Encryption that gives you the ability to encrypt your alert and incident information as it travels to and from the incident management solution.
• We have heartbeats to ensure alerting works end-to-end by checking that monitoring tools are active and connected, and that custom tasks are completed on schedule. 
• On top of all the prior feature set, Opsgenie costs less. Compare and see it yourself in our pricing page.
• Finally, we have a great customer success team and with Opsgenie Enterprise plan, you have 24X7 chat, email, and phone support.

These are just some of the obvious advantages. If you need more detailed explanation or a demo, you can reach out to customer success team on the contact us page. 

[Serhat Can]

Oh, and I just remembered we have this amazing blog post on this exact topic. 

https://www.atlassian.com/blog/it-teams/the-top-10-reasons-companies-are-choosing-opsgenie