<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<p dir="ltr">The information you gather by monitoring your vendors is priceless, if you are able to determine within a short period of time that your vendor is the problem,you have just saved precious time in identifying the problem. You can then reroute around
the issue, instead of spending time in looking at your platform</p>
<div class="x_quote">On Apr 23, 2017 3:10 PM, Peter Beckman <beckman@angryox.com> wrote:<br type="attribution">
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Yep, we monitor our vendors. In some cases, better than they monitor<br>
themselves. It's frustrating that they don't/can't/won't, but wanting them<br>
to change doesn't help our customer experience. So we do it for<br>
them proactively.<br>
<br>
Too many outages on our vendor services have been caused by their<br>
ineptitude, such as this Plivo outage. We decided as a result of this Plivo<br>
ouatge that, while it was only merely annoying to our Operations team and<br>
didn't result in any customer-facing issues, we could have seen this coming<br>
and maybe averted this disaster for everyone by adding two config lines in<br>
our monitoring platform and a process to ensure notification to, followup<br>
with and closure of the issue with Plivo.<br>
<br>
The cost to our Operations team is small, the automated monitoring costs<br>
nothing, but the impact of knowing that our vendors are having (or will<br>
have) issues before they tell us or know themselves, AND before our<br>
customers complain, improves our customer experience and operational<br>
excellence despite our vendor's failings.<br>
<br>
It also gives us a chance to write defensive code to handle the situations<br>
where the vendor is not meeting their contractually obligated level of service.<br>
<br>
Beckman<br>
<br>
<br>
On Sun, 23 Apr 2017, Keln Taylor wrote:<br>
<br>
> Just to clarify, you are saying that you monitor the domain and SSL cert of<br>
> your vendors so you can notify them?<br>
> That's cool.<br>
><br>
><br>
> Sincerely,<br>
> Keln Taylor<br>
> 870-204-2121<br>
> kelntaylor@gmail.com<br>
><br>
> On Sun, Apr 23, 2017 at 12:31 PM, Peter Beckman <beckman@angryox.com> wrote:<br>
><br>
>> We should all strive to NOT do that. We integrated a once a day check into<br>
>> our Monitoring platform that starts warning Operations 30 days before the<br>
>> domain expires, and actually pages people starting at 9am on Weekdays 7<br>
>> days before if it hasn't been renewed. We had to tweak it for how our<br>
>> registrar publishes that information, and we automated renewals so it<br>
>> rarely goes off, but when it does we can get in front of it.<br>
>><br>
>> We have the same thing in place for our public and internal SSL/TLS<br>
>> Certificates.<br>
>><br>
>> If you are running a business on the web and don't automate monitoring of<br>
>> critical infrastructure, you get outages like this. Heck, we started<br>
>> monitoring the domain and SSL certs of our critical-path dependent<br>
>> services/vendors since another outage many years ago after an SSL cert<br>
>> expired.<br>
>><br>
>> Plivo wasn't in our mix, as they aren't critical-path, but they are now,<br>
>> and they are still in alarm. Operations now will be automatically notified<br>
>> when we can actually see Plivo again.<br>
>><br>
>> Beckman<br>
>><br>
>> On Sun, 23 Apr 2017, Gavin Henry wrote:<br>
>><br>
>> On 23 April 2017 at 17:31, Alex Balashov <abalashov@evaristesys.com><br>
>>> wrote:<br>
>>><br>
>>>><br>
>>>> I've done it. Just got distracted, got to fiddling around and thinkin'<br>
>>>> bout things, and before I know it, the domain's expired and I'm no longer<br>
>>>> on the register of respectable party guests...<br>
>>>><br>
>>><br>
>>> Embarrassing. I'm sure I'll do it at some point. :-)<br>
>>><br>
>>><br>
>> ------------------------------------------------------------<br>
>> ---------------<br>
>> Peter Beckman Internet Guy<br>
>> beckman@angryox.com<br>
>> <a href="http://www.angryox.com/">http://www.angryox.com/</a><br>
>> ------------------------------------------------------------<br>
>> ---------------<br>
>> _______________________________________________<br>
>> VoiceOps mailing list<br>
>> VoiceOps@voiceops.org<br>
>> <a href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
>><br>
><br>
<br>
---------------------------------------------------------------------------<br>
Peter Beckman Internet Guy<br>
beckman@angryox.com <a href="http://www.angryox.com/">
http://www.angryox.com/</a><br>
---------------------------------------------------------------------------<br>
_______________________________________________<br>
VoiceOps mailing list<br>
VoiceOps@voiceops.org<br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
</div>
</span></font>
</body>
</html>