charity

mongodata3:SECONDARY> c.find({ $query: {ppoi_0: { $nearSphere: [ -74.5287, 40.1301 ], $maxDistance: 0.02601798524805497 } , deviceType: "ios", channels: { $in: [ "featured_coupons", "special_sales" ] }, appVersion: { $in: [ "3.0", "3.0.1", "3.1", "3.5" ] } }}).explain()
{
        "cursor" : "BasicCursor",
        "isMultiKey" : false,
        "n" : 0,
        "nscannedObjects" : 6484024,
        "nscanned" : 6484024,
        "nscannedObjectsAllPlans" : 6484024,
        "nscannedAllPlans" : 6484024,
        "scanAndOrder" : false,

charity

$ for svc in $(aws list 3>&1 1>&2 2>&3 3>&- | sed -e '1,7d' |sed -e 's/\|//g') ; do aws $svc describe-account-attributes 2>/dev/null || echo "not supported for $svc" ; done

charity

Failure is Not Optional -- it will happen

http://highscalability.com/blog/2010/10/15/troubles-with-sharding-what-can-we-learn-from-the-foursquare.html
https://web.archive.org/web/20110209190434/http://blog.foursquare.com/2010/10/05/so-that-was-a-bummer/

https://www.joyent.com/blog/postmortem-for-outage-of-us-east-1-may-27-2014

https://aws.amazon.com/message/5467D2/

http://perfcap.blogspot.com/2012/11/cloud-outage-reports.html

charity

Introducing a new series: Post-Mortem Book Reports

Dear fellow systems engineers,

Take a moment and think about the past few years in systems outages and public post mortems. 

What were your favorite outages?  What are the post-mortems that you read that stick with you, months or years or years and years later?  What did you learn from them?

If you are in AWS us-east-1, you probably think back to the Christmas Eve outage of 2013 or the long string of EBS outages.  If you were an early user of mongo sharding, I'm betting the 4sq mongo outage is etched into your brain.  If you run physical data centers and run your own networking or experience lots of DDOS attempts, GitHub post mortems are probably high on your list.

charity

Introducing a new series: Post-Mortem Book Reports

Dear fellow systems engineers,

Take a moment and think about the past few years in systems outages and public 
post mortems.

What were your favorite outages?  What are the post-mortems that you read that 
stick with you, months or years or years and years later?  What did you learn
from them?

charity

# file name: infra/terraform/modules/aws_vpc/bastion_sg.tf

resource "aws_security_group" "bastion_ssh_sg" {
  name = "bastion_ssh"
  description = "Allow ssh to bastion hosts for each vpc from anywhere"
  ingress {
    from_port = 22
    to_port = 22
    protocol = "tcp"
    cidr_blocks = ["0.0.0.0/0"]

charity

# file name terraform/modules/aws_vpc/vpc.tf
# first create the VPC.
# Prefix resources with var.name so we can have many environments trivially

resource "aws_vpc" "mod" {
  cidr_block = "${var.cidr}"
  enable_dns_hostnames = "${var.enable_dns_hostnames}"
  enable_dns_support = "${var.enable_dns_support}"
  tags { 
    Name = "${var.env}_vpc"

charity

# file name: terraform/env-staging/peering.tf
# No peering / direct connectivity between staging and prod, for safety.

resource "terraform_remote_state" "dev_state" {
  backend = "s3"
  config {
    bucket = "${var.tf_s3_bucket}"
    region = "${var.region}"
    key = "${var.dev_state_file}"
  }

charity

# snippet from terraform/env-dev/peering.tf

# import staging state, add routes from dev to staging
resource "terraform_remote_state" "staging_state" {
  backend = "s3"
  config {
    bucket = "${var.tf_s3_bucket}"
    region = "${var.region}"
    key = "${var.staging_state_file}"
  }

charity

#!/bin/bash -xe
# requires jq 1.5 (or at least > 1.3) and kafkacat

PATH=$PATH:/usr/lib/kafka/bin
topic="hound-staging.retriever-mutation"

which kafkacat || echo 'no kafkacat found, bye!' && exit 1
which jq || echo 'no jq found, bye!' && exit 1

# make sure jq is v 1.5