Пятничный деплой

time.AfterFunc(3*time.Second, func() {
        fmt.Println("Executed after 3 seconds")
    })

ticker := time.NewTicker(2 * time.Second)
    defer ticker.Stop()

    for i := 0; i < 3; i++ {
        <-ticker.C
        fmt.Println("Task executed at:", time.Now())
    }

c := cron.New()

    // Планируем задачу каждые 5 секунд
    c.AddFunc("*/5 * * * * *", func() {
        fmt.Println("Cron job executed at:", time.Now())
    })

    c.Start()

s := gocron.NewScheduler(time.UTC)

    s.Every(10).Seconds().Do(func() {
        fmt.Println("Scheduled task executed at:", time.Now())
    })

    s.StartAsync()

* * * * * /path/to/your-go-program

var UserSchema = zog.Object(map[string]zog.Schema{
  "username": zog.String().Min(3).Max(20),
  "email":    zog.String().Email(),
  "age":      zog.Number().Min(18),
})

func main() {
  data := map[string]interface{}{
    "username": "go_dev",
    "email":    "[email protected]",
    "age":      25,
  }

  parsed, err := UserSchema.Parse(data)
  if err != nil {
    fmt.Println("Ошибка валидации:", err)
    return
  }

  fmt.Println("Успешно:", parsed)
}

#!/bin/bash

set -euo pipefail

readonly PORT=8001
readonly POD=echoserver
readonly TARGETIP=1.1.1.1

while true; do
  curl -v -H 'Content-Type: application/json' \
    "http://localhost:${PORT}/api/v1/namespaces/default/pods/${POD}/status" >"${POD}-orig.json"

  cat $POD-orig.json |
    sed 's/"podIP": ".*",/"podIP": "'${TARGETIP}'",/g' \
      >"${POD}-patched.json"

  curl -v -H 'Content-Type:application/merge-patch+json' \
    -X PATCH -d "@${POD}-patched.json" \
    "http://localhost:${PORT}/api/v1/namespaces/default/pods/${POD}/status"

  rm -f "${POD}-orig.json" "${POD}-patched.json"
done

kind: Node
apiVersion: v1
metadata:
  name: fakegoogle
status:
  addresses:
  - address: www.google.com
    type: Hostname

curl http://127.0.0.1:8001/api/v1/nodes/http:fakegoogle:80/proxy/

apiVersion: grizzly.grafana.com/v1alpha1
kind: Dashboard
metadata:
    name: prod-overview
    folder: general
spec:
    schemaVersion: 17
    tags:
        - templated
    timezone: browser
    title: Production Overview
    uid: prod-overview

My book is a 170+ page guide for optimizing the performance of applications that run on modern CPUs. It combines the knowledge of many experts from different industries, to whom I'm very thankful. Engineers from Google, Facebook, leading HFT, and game development firms helped me shape this book

15 октября мы раскатили прошивку на 10% устройств. Поэтапная раскатка обновления — это стандартная практика. Она предназначена в том числе для того, чтобы выявлять проблемы новых версий на ранней стадии. И прежде чем увеличивать процент раскатки, мы отсматриваем метрики всех ключевых пользовательских сценариев. Но число генерируемых нами NTP‑запросов исторически никогда не входило в метрики, требующие валидации, потому что NTP‑клиент годами существовал практически без изменений и не приводил к проблемам.

К 24 октября новая прошивка докатилась до 100% колонок. Опять же, критичные для пользователей сценарии покрыты автоматическим мониторингом. Если что‑то важное ломается, мы получаем уведомление. Но, как вы уже догадались, для NTP‑клиента таких уведомлений настроено не было.
. . .
Жалоб было мало, действующий регламент поддержки не был рассчитан на подобные ситуации, поэтому обращения рассматривали не в самом высоком приоритете. К 20 ноября мы нашли ошибку, внесли исправление в код и начали готовить новый релиз.

В выходные 23–24 ноября ситуация с NTP‑серверами обостряется: доступными остаются лишь четыре сервера. К этому моменту мы уже начали раскатывать релиз с исправлением на 10% устройств.
. . .
В воскресенье мы выпустили хотфикс в виде новой рантайм‑конфигурации для NTP‑клиента, который увеличивал период перезапроса с 5 до 600 секунд, уменьшая нагрузку на серверы в 120 раз. Хотфикс не исправлял проблему полностью, но был единственным быстрым способом снять чрезмерную нагрузку с NTP-серверов.
. . .
мы запланировали выделить ресурсы в общий пул NTP‑серверов. Это займёт некоторое время, потому что наши дата‑центры удалены от основных точек обмена трафиком, а для NTP‑серверов RTT (Round Trip Time) это — ключевой фактор качества. Мы установим и запустим мощности на основных точках обмена трафиком.

Для наших устройств мы заведём именную зону в соответствии с гайдлайнами проекта NTPPool.org для бо́льшей прозрачности. Генерируемый ими трафик будет локализован на наших NTP‑серверах, если мы продолжим полагаться на публичную инфраструктуру проекта.

Ещё мы добавим метрики, связанные с NTP, на этап валидации A/Б‑экспериментов, а также реалтайм‑уведомления о неполадках в этом компоненте. В том числе расширим сценарии мониторинга исходящего и входящего служебного трафика устройства в целом. Также поработаем над каналами коммуникаций и поддержкой, чтобы подобные проблемы быстрее до нас эскалировались.

#!/usr/bin/perl

use strict;
use warnings;

my %numbs;
select STDERR;
while(<STDIN>) {
    if( /^[0-9]++\s++([a-z0-9_]++(?=\())/ ) {
        my $t = ++$numbs{$1};
        s/\s+/ \e[31m$t\e[m /;  
        die $! if( keys %numbs == 1000 );
    }
    print;
}
exit(0);

strace -o'|./num_syscalls' -yf sh -c 'ls|cat'

456107 48 close(3</usr/) = 0
456107 52 rt_sigreturn({mask=[]}) 
456107 63 openat(AT_FDCWD</usr/local/sbin>)
456107 53 newfstatat(3)
456107 64 openat(AT_FDCWD</usr/local/sbin>)

strace -o'|./num_syscalls' -yf ls > /dev/null

Falco Talon is a Response Engine for managing threats in Kubernetes clusters. It enhances the solutions proposed by the Falco community with a no-code tailor-made solution. With easy rules, you can react to events from Falco in milliseconds.

- kubernetes:terminate
- kubernetes:label
- kubernetes:networkpolicy
- kubernetes:exec
- kubernetes:script
- kubernetes:log
- kubernetes:delete
- kubernetes:drain
- kubernetes:download
- kubernetes:tcpdump
- aws:lambda
- calico:networkpolicy
- cilium:networkpolicy

127։0։0։1
127·0·0·1
127․0․0․1