Wdrożenie
Nie ma tu instalacji do samodzielnego rozgryzienia. Observera wdraża się w jednej poprowadzonej sesji — nasi inżynierowie ramię w ramię z Twoim zespołem DevOps, na Twoim sprzęcie. Dostęp do kodu źródłowego następuje po NDA i licencji; samo wdrożenie jest celowo krótkie.
Sesja onboardingu
Każdy krok poniżej jest wykonywany wspólnie: my prowadzimy, Twój zespół DevOps zatwierdza, obserwuje i uczy się runbooków w miarę ich powstawania.
ClickHouse 24.8, collector oraz API/dashboard trafiają na Twój VPS — albo na Twój plus naszą maszynę stagingową. Docker Compose na ścieżkę gotową od ręki albo gołe procesy Node 22 pod systemd. Dobieramy maszynę z Twoim DevOpsem i razem startujemy usługi.
Generujemy konfiguracje witryn podpisane Ed25519 i rejestrujemy Twoją pierwszą witrynę — zablokowaną do jej listy dozwolonych witryn. Tworzymy użytkownika admina i wspólnie, na żywo w rozmowie, włączamy dwuskładnikowe TOTP.
Schemat ClickHouse jest aplikowany z TTL-ami wymuszonymi na poziomie storage: surowe zdarzenia 24 godziny, rollupy 25 miesięcy, nagrania 30 dni. Potem zasiewamy 14 dni wzorcowych danych demo, więc każdy ekran żyje, zanim przyjdzie Twój pierwszy prawdziwy odwiedzający.
Twoja strona dodaje jeden rekord A wskazujący na serwer. TLS konfigurujemy z Twoim DevOpsem, a snippet jest zablokowany do Twojej listy dozwolonych witryn — ten sam kod wklejony na innej witrynie zostaje odrzucony na collectorze błędem 403.
Twoja pierwsza odsłona strony zapala kreator dodawania witryny na zielono, z rosnącym licznikiem odsłon. Potem na TWOIM wdrożeniu uruchamia się 6-specyfikacyjna przeglądarkowa suita prywatności — zero cookies, zero zapisu, scrubbing PII end-to-end — a raport trafia do Twojego DevOpsu.
Kroki 1–3 to zwykle jedna sesja; propagacja DNS (krok 4) to jedyny element z wbudowanym oczekiwaniem. Dane demo z kroku 3 są wyraźnie oznaczone i znikają, gdy tylko startuje Twój prawdziwy ruch.
Co dociera do Ciebie na piśmie
Przed onboardingiem jedyny kod Observera, jaki kiedykolwiek dotyka Twoich systemów, jest generyczny: kontener datastore, który Twój DevOps może provisionować zawczasu, i jednolinijkowy snippet, który niosą Twoje witryny. Wszystko poza tymi dwiema linijkami — klucze, konfiguracje, runbooki — jest wydawane podczas sesji, po NDA.
# step 1 · the datastore — sized and run together with your DevOps docker run -d --name observer-ch -p 127.0.0.1:8124:8123 \ -e CLICKHOUSE_USER=observer \ -e CLICKHOUSE_PASSWORD=******** \ clickhouse/clickhouse-server:24.8 # step 4 · the only line your websites get — domain-locked, async, cookie-less <script async src="https://sa.yourdomain.com/v.js" data-site="obs_XXXX"></script>
Dane uwierzytelniające są wybierane z Twoim DevOpsem podczas sesji i nigdy nie pojawiają się w dokumentacji. ClickHouse domyślnie binduje się do localhosta; collector (:8090) oraz API/dashboard (:8081) to jedyne nasłuchy, których potrzebują Twoje witryny i zespół.
Po sesji
Konfiguracje podpisane Ed25519 dla każdej zarejestrowanej witryny, zablokowane do ich list dozwolonych witryn. Rozszerzenie listy — staging, subdomeny, zapasowe domeny — to zmiana na jedną komendę, którą Ci przekazujemy.
Tokeny witryn, klucze API ze scope'ami, role RBAC owner · admin · analyst · viewer — plus runbooki operacyjne spisane podczas sesji. Wszystko przechowywane na Twoim sprzęcie.
Bezpośredni kanał do inżynierów, którzy przeprowadzili Twoje wdrożenie: wspólne monitorowanie, aktualizacje umawiane jako podmiana konfiguracji, ponowny przebieg suity prywatności przy każdej aktualizacji.
Przywieź VPS-a i inżyniera DevOps. My przywozimy stack, klucze, schemat i weryfikację — a całość żyje po jednej sesji.