0 просмотренных постов скрыто
Социальные сети как новая инфраструктура будущего
Социальные сети будущего
Если вы всё ещё думаете, что социальные сети — это всего лишь площадки для селфи и котиков, то вы упускаете главный тренд десятилетия. Социальные сети перестали быть просто приложениями для общения, превратившись в операционную систему новой экономики и интерфейс, через который человечество будет управлять городами, заводами, роботами и даже собственными биоритмами.
Для инвестора это означает одно, что в ближайшие 5–10 лет капитализация компаний, которые строят социально-ориентированную цифровую инфраструктуру, может вырасти в сотни и тысячи раз, но чтобы увидеть этот потенциал, нужно посмотреть на соцсети не как на медиа, а как на нервную систему планеты, через которую будет идти управление всеми ключевыми процессами будущего.
IoT и умные города, соцсеть как пульт управления реальностью
Интернет вещей (IoT) уже сегодня насчитывает десятки миллиардов подключённых устройств от холодильников до промышленных датчиков, но кто будет координировать всё это? Кто даст человеку простой и понятный способ взаимодействовать со всем этим роем?
Социальные сети, где не надо запускать отдельные приложения для каждого устройства, а можно коммуницировать с ними через привычные каналы, голосовые сообщения, чаты, ленты событий. Представьте, что ваш городской транспорт, система освещения, аварийные службы и коммунальные сети — это не просто набор серверов, а «друзья» в вашей ленте.
Социальные сети становятся универсальным API для взаимодействия человека с машинами, аккумулируя данные от миллионов устройств, обрабатывая их и возвращая человеку в виде понятных уведомлений, советов или автоматических действий. Инвесторы, которые вкладываются в развитие таких платформ, фактически покупают долю в инфраструктуре управления миром.
Транспорт и логистика, соцсети как диспетчерская будущего
Управление транспортными потоками — это всегда проблема координации миллионов агентов. Традиционные системы слишком локализованы. Будущее за децентрализованными социальными алгоритмами, которые обрабатывают желания и потребности каждого участника движения в реальном времени.
Представьте, что каждый автомобиль и беспилотник — это «пользователь» в глобальной социальной сети, обменивающийся данными о маршрутах, пробках, погоде и аварийных ситуациях. Но фишка в том, что сеть не просто передаёт данные, а учится на поведении миллиардов людей, предлагая оптимальные маршруты, подстраивает графики общественного транспорта под нужды города, синхронизирует доставку товаров с пиками спроса.
Для инвестора здесь скрыт огромный рынок. Платформы, которые станут посредниками между транспортными операторами и конечными пользователями, получат доступ к бесценной поведенческой аналитике и смогут монетизировать каждое перемещение. Социальная сеть превращается в глобального диспетчера, её ценность будет измеряться не количеством лайков, а количеством успешно доставленных грузов и сэкономленных часов работы человека.
Когда роботы становятся частью нашего круга общения
Роботы перестают быть бездушными механизмами, становясь нашими помощниками, коллегами, ассистентами, компаньонами, а иногда и партнёрами по игре. Чтобы робот эффективно взаимодействовал с человеком, он должен понимать социальный контекст, настроение, культуру, невербальные сигналы. Именно социальные сети накапливают колоссальные массивы данных о том, как люди общаются, шутят, злятся и радуются.
В будущем каждый домашний или промышленный робот будет подключён к единой социальной экосистеме, получая обновления поведения, учась на опыте миллионов других роботов и адаптируясь к конкретному пользователю. Мы не будем программировать их, можно просто «дружить» с ними через тот же интерфейс, через который общаемся с людьми.
Это создаёт новый класс инвестиционных возможностей, где платформы, обеспечивающие социальную интеграцию роботов, становятся основой для рынка роботизированных услуг, который уже к 2030 году может превысить триллион долларов. Эта интеграция будет происходить именно через социальные сети.
Социально-экономические трансформации. новые модели труда и капитала
Социальные сети уже изменили экономику! Фриланс, краудфандинг, децентрализованные автономные организации выросли из способности людей быстро находить друг друга и координироваться без посредников, но это лишь начало. В ближайшие годы социальные платформы станут биржей талантов и капитала нового типа. Через них будут заключаться контракты, оцениваться репутация, приниматься коллективные решения о распределении ресурсов. Мы увидим появление социальных кредитных систем, где наша активность и вклад в сообщество будут определять доступ к финансированию, страхованию и даже политическим правам.
Для инвестора это означает, что компании, которые строят инфраструктуру доверия и координации на основе социальных графов, могут стать более ценными, чем многие традиционные банки. Они будут владеть не деньгами, а репутацией и связями, что намного важнее в цифровую эпоху.
Маркетинг и реклама, от таргетинга к персонализации
Реклама всегда была двигателем интернета, но будущее маркетинга — это не показ баннеров, а глубокая интеграция брендов в повседневные социальные взаимодействия. Потребитель не хочет видеть рекламу, а хочет, чтобы бренд был частью его круга общения, советовал, развлекал и помогал уму в жизни.
Социальные сети собирают данные о намерениях, контексте, окружении человека в реальном времени, что позволяет предлагать товары и услуги в момент возникновения потребности, причём в форме, неотличимой от совета друга. Эффективность такой рекламы будет на порядок выше нынешней.
Но главное в том, что социальные сети перестанут быть просто каналом доставки рекламы, а станут пространством совместного создания ценностей, где бренды и потребители взаимодействуют, разрабатывают продукты вместе, голосуют за дизайн, тестируют прототипы. Это радикально меняет всю цепочку создания стоимости. Инвесторы, которые осознают этот сдвиг, будут вкладываться не в рекламные сети, а в платформы коллаборации, где социальное взаимодействие является главным двигателем экономики.
Виртуальная реальность, когда мир становится интерфейсом
Виртуальная и дополненная реальность — это не просто игры и развлечения, а новый способ присутствия, который стирает границы между физическим и цифровым. Социальные сети станут местом соединения миллионов виртуальных миров, создавая единую метавселенную или пространство, где люди работают, учатся, путешествуют, встречаются и... живут.
В этой метавселенной социальные сети станут не просто приложением, а самим пространством, где можно просто жить. Цифровой аватар, репутация и виртуальные активы будут привязаны к единой социальной идентичности.
Для инвестора это открывает горизонты в рынок виртуальной недвижимости, цифровых предметов, образовательных сред, корпоративных симуляторов и всё это будет работать на социальной инфраструктуре. Платформы, которые обеспечат грамотный переход между физическим и виртуальным, станут главными бенефициарами этого бума.
Главный императив человека это общение
За всеми технологическими терминами стоит простой и неизменный факт, что человек существо социальное. Мы не можем жить без общения, принадлежности к группе, признания и взаимопонимания. Все перечисленные технологии — это лишь инструменты, которые усиливают эту потребность, но не отменяют её.
Социальные сети будущего успешны, когда могут удовлетворить глубинную человеческую потребность в связи. Именно это делает их неуязвимыми для любых технологических циклов. Пока люди будут хотеть делиться мыслями, чувствами и опытом, получать одобрение и эмоции, будет существовать спрос на платформы, которые это предоставляют.
Вложения в технологии социальных сетей будут расти по мере того, как мир будет становится сложнее и быстрее.
Социальные сети как фундамент будущего
Мы стоим на пороге эпохи, где социальные сети перестанут быть отдельной индустрией и станут операционной системой будущего всех остальных отраслей. Управление транспортом, координация роботов, персонализированная медицина, инновационное образование и т.д. и т.п..
Для инвестора это означает, что нужно смотреть не на текущие метрики, а на стратегическую роль платформы в будущей экосистеме. Те компании, которые смогут предложить открытую, безопасную, удобную социальную инфраструктуру для всех этих сценариев, станут гигантами следующего поколения.
Социальные сети — это не пузырь и не хайп, а огромный эволюционный шаг в развитии нашей цивилизации. Мы переходим от общества телефонов и бумаг к цифровому обществу и в этом новом мире социальная сеть занимает приоритетное место.
Показать полностью
Ответ на пост «Почему же они не покупают?»2
Делаю ровно такой сервис с подпиской, так что этот пост буквально про меня — вплоть до митингов «может, с функционалом что-то не то?»)
Открою тайну с той стороны стола: вторая картинка — не карикатура, мне это пишут почти дословно. И люди правы. Их столько раз ловили на «а со второго месяца 999» и «отпишись попробуй», что теперь за это расплачивается любой, кто выходит с подпиской, — даже если у него всё честно. Такой налог на чужую хитрость, и платят его все новенькие. Свежий пример — Яндекс Плюс: я недавно отписывался, так кнопку отписки прятали от меня дольше, чем когда-то уговаривали подписаться.
У себя из-за этого сделал вход только по почте, без телефона — сам не люблю оставлять номер хрен пойми кому. И убрал автопродление с автосписаниями совсем: кончился срок — просто кончился, никто ничего не снимет, пока сам не продлишь. Вот это, кстати, реально помогло. А вот недоверие к подпискам как к жанру никаким интерфейсом до конца не лечится.
Так что ответ на вопрос с первой картинки: они не покупают не потому, что дорого. Они уже платили «стакан кофе в месяц» — и помнят, чем это закончилось.
Не отставайте от рынка: обновите навыки, которые нужны компаниям уже сейчас
До 17 сентября в Яндекс Практикуме действует скидка 16% на любой онлайн-курс — можно выбрать новое направление или прокачать имеющиеся навыки. А еще есть курсы, которые помогут разобраться с ИИ и встроить нейросети в работу.
Реклама. ООО «Яндекс», ИНН: 7736207543
Инлайн-кнопка одна на всех: параметры, аутентификация и обратная связь в Telegram miniapp
Примеры кода — на C#/.NET, потому что так написан наш прод. Но вся статья — про механику Telegram, а не про язык: то же самое собирается на Node, Python или Go без изменений. Именно ради переносимой механики статья и написана.
О чём статья? Это вторая часть серии о том, как мы вайб-кодингом построили GoosleeBot — мост из Telegram в Google Meet, Zoom и другие сервисы видеовстреч. Здесь — самая недокументированная часть разработки под Telegram: механизм сессий, который связывает чат, miniapp и внешний браузер в одно приложение. Вот что внутри:
как передать параметры из инлайн-бота в miniapp, если кнопка в чате одна на всех участников;
как аутентифицировать пользователя miniapp за один запрос — с готовым скелетом валидации initData;
как сохранить состояние там, где переменные Telegram не работают вовсе — во внешнем браузере;
как доставлять изменения из чата в miniapp мгновенно (спойлер: WebSocket в telegram-webview работает);
как редактировать сообщения в чате асинхронной очередью и не словить бан от Bot API;
и другие.
А это вся серия:
Часть 1 — история продукта и честный вердикт Telegram как платформе: правила для памяти агента, функция «где я?», туннели.
Часть 2 (вы здесь) — механизм сессий: параметры, аутентификация, обратная связь, редактирование без бана.
Часть 3 — UX-хаки: бот, который «звонит» как телефон, онбординг-воронка одним JSON-файлом и почему ссылки надо готовить до клика.
Проблема: кнопка общая, ссылка тупая, а половина флоу — вообще не в Telegram
Наш главный сценарий выглядит невинно: в чате лежит сообщение бота с кнопкой «Присоединиться к звонку». Но у этой кнопки три неприятных свойства, о которых не пишут в туториалах:
Первое: кнопка одна на всех. Сообщение в чате общее — его видят все участники. Нажать может любой, и для каждого miniapp должен открыться со «своим» контекстом: кто ты, в каком звонке, что тебе можно. А кнопка умеет ровно одно — открыть ссылку. Одинаковую для всех.
Второе: нужна аутентификация и обратная связь. Мало открыть страницу — надо понять, кто её открыл (и не поверить на слово), а потом вернуть результат действий обратно: в сообщение в чате, другим участникам, в их miniapp.
Третье, самое коварное: часть флоу уходит во внешний браузер. OAuth-авторизация у Google или Zoom по правилам провайдеров происходит в системном браузере — и в момент, когда пользователь туда перешёл, все переменные miniapp перестают существовать. Нет `Telegram.WebApp`, нет initData, нет ничего. Из всего контекста Telegram остаётся ровно то, что вы сами успели положить в URL.
Три проблемы — одно решение: серверные сессии. И сразу важная рамка: это не трюк для проброса параметров. Это полноценный аналог классической веб-сессии — серверный объект с временем жизни и типизированным хранилищем значений, на котором держится вся серверная логика. Если в вашем продукте есть хотя бы сценарий «выйти из miniapp наружу и вернуться» — механизм сессий обязателен, без вариантов.
Сессия как серверный объект
Скелет предельно простой (напоминаю, здесь C#, но это словарь с TTL — он есть в любом языке):
```csharp
public sealed class Session
{
public string Key { get; init; } // Guid без дефисов — едет в URL
public SessionType SessionType { get; set; } // RequestCall | MiniAppRoute | AccessToken | ...
public TimeSpan SessionLifeTime { get; set; }
public bool IsExpired => UtcNow - CreatedDate > SessionLifeTime;
public T? GetData<T>() where T : class { ... } // типизированные данные сценария
public void SetData<T>(T? value) where T : class { ... }
}
```
Хранилище — обычный `ConcurrentDictionary<string, Session>` в памяти процесса, фоновый воркер выметает протухшие. Ключ — случайный Guid: он непредсказуем, поэтому сам по себе работает как секрет.
Главное здесь — `GetData<T>()`. У каждого типа сессии свой класс данных, и это данные не «для передачи», а рабочее состояние, на которое опирается серверная логика. Например, у сессии инлайн-звонка внутри лежит: кто создал звонок, список пользователей, нажимавших кнопки, выбранный провайдер, статус звонка, id инлайн-сообщения в чате, последний отрисованный текст этого сообщения. Сервер читает и меняет это состояние на каждом шаге сценария — ровно как классическая сессия в вебе, просто ключ к ней приезжает не в cookie (помните правило из части 1: cookies в webview ненадёжны), а в URL и токенах.
Цепочка: от кнопки в чате до персональной страницы
Теперь само решение — цепочка из трёх сессий. Звучит громоздко, на деле — три словарных записи и два редиректа:
```text
[чат] RequestCall-сессия ─── общая, одна на звонок
│ ключ уезжает в кнопку: t.me/MyBot/app?startapp= {key}
▼
[miniapp] роутер-страница: собирает Telegram.WebApp.initData → POST /init
│ сервер валидирует подпись, находит RequestCall по ключу
▼
[сервер] AccessToken-сессия ── персональная, у каждого пользователя своя,
│ внутри ссылка на общую OriginalSession
▼
[страница] редирект на целевую страницу с персональным токеном в URL
```
По шагам:
1. Создание. Когда пользователь вызывает бота в чате, сервер создаёт `RequestCall`-сессию — общую для этого звонка. Ключ уходит в кнопки. Для callback-кнопок мы кодируем его прямо в payload (`{key}@@@{команда}`), для кнопки miniapp — в параметр `startapp` диплинка. Это единственный канал: Telegram не даст кнопке передать ничего, кроме этой строки.
2. Роутер. Кнопка открывает не целевую страницу, а лёгкую страницу-роутер. Её JS собирает `initData` и шлёт на сервер:
```js
const tg = window.Telegram.WebApp;
const resp = await fetch('/miniapp/init', {
method: 'POST',
body: JSON.stringify({
initData: tg.initData, // подписанная строка — для проверки
startParam: tg.initDataUnsafe.start_param, // ключ RequestCall-сессии
platform: tg.platform, // помните «где я?» из части 1
}),
});
const { redirectUrl } = await resp.json();
location.replace(redirectUrl);
```
3. Проверка и обмен. Сервер валидирует подпись initData (следующий раздел), находит общую сессию по ключу из `start_param` — и выпускает персональную `AccessToken`-сессию: «пользователь X в контексте звонка Y». Внутри неё — ссылка на общую:
```csharp
var accessSession = SessionService.Create(SessionType.AccessToken, lifeTime);
accessSession.SetData(new AccessTokenSessionData {
UserId = user.Id,
OriginalSession = requestCallSession, // общий контекст звонка — один на всех
});
return RedirectUrlFor(page, accessSession.Key); // токен — в URL целевой страницы
```
Одна общая сессия звонка — много персональных токенов поверх неё. Любой запрос с целевой страницы несёт персональный токен, и сервер за один lookup знает и «кто», и «в каком звонке». Проблема «кнопка одна на всех» решена.
4. Внешний браузер. А теперь то, ради чего это всё. Когда пользователь уходит на OAuth к Google и возвращается на наш callback-URL — он приходит в обычном браузере, без единой переменной Telegram. Но токен-то мы положили в URL заранее. Сервер достаёт по нему AccessToken-сессию → из неё OriginalSession → и продолжает сценарий, как будто никто никуда не уходил. Состояние пережило переход чат → miniapp → внешний браузер → обратно, потому что оно никогда и не покидало сервер.
Аутентификация: не верьте `initDataUnsafe` на слово
Telegram кладёт в miniapp данные пользователя двумя способами: `initDataUnsafe` (удобный распарсенный объект) и `initData` (сырая строка с криптографической подписью). Слово «Unsafe» в названии — не кокетство: эти данные каждый умеет подделать, отправив вам любой user_id. Использовать их для UI — можно, для серверных решений — только после проверки подписи сырой строки.
Алгоритм проверки описан в доках Telegram, вот его скелет целиком — это один статический метод:
```csharp
public static bool Validate(string initData, string botToken)
{
var parsed = ParseQuery(initData); // initData — это query string
var receivedHash = parsed["hash"];
var dataCheckString = string.Join('\n', // все поля кроме hash,
parsed.Where(kv => kv.Key != "hash") // отсортированы по ключу
.OrderBy(kv => kv.Key, StringComparer.Ordinal)
.Select(kv => $"{kv.Key}={kv.Value}"));
var secretKey = HMACSHA256(key: "WebAppData", message: botToken);
var expected = HMACSHA256(key: secretKey, message: dataCheckString);
if (!FixedTimeEquals(expected, receivedHash)) return false; // константное время!
return UtcNow - FromUnix(parsed["auth_date"]) < MaxAge; // и свежесть: у нас 1 час
}
```
Три детали, которые агент при вайб-кодинге стабильно упускает — проверьте руками:
Сортировка полей ordinal, не culture-зависимая — иначе подпись «иногда не сходится».
Сравнение хэшей в константное время (`FixedTimeEquals`), а не `==` — защита от timing-атак на подбор подписи.
Проверка `auth_date`. Подпись без срока годности — это вечный пропуск: перехваченная один раз строка initData работала бы годами.
После валидации `user_id` из initData можно считать доказанным — Telegram расписался. Заметьте, что получилось: регистрация, логин и восстановление пароля в вашем приложении не существуют как задачи. Это одна из главных причин строить бизнес-приложения на Telegram вообще.
Врезка честности: всё это лежит в памяти процесса
Да, наши сессии — in-memory, `ConcurrentDictionary`, без Redis. Это осознанный трейдофф, и вот его границы:
Когда это нормально: один инстанс приложения; сессии короткоживущие (минуты-часы) и по природе восстановимые — пользователь в худшем случае нажмёт кнопку ещё раз; критичное для бизнеса состояние (звонки, пользователи, настройки) и так живёт в PostgreSQL, сессия лишь оркестрирует сценарий.
Когда сломается: рестарт или деплой обнуляет живые сценарии (у нас это «кнопка перестала отвечать, вызовите меню заново»); второй инстанс за балансировщиком не увидит чужих сессий — привет, sticky sessions или внешний стор.
Для вайб-кодера мораль такая: начинайте со словаря в памяти — это ноль инфраструктуры и вся механика статьи работает как есть. Но заведите интерфейс хранилища сессий с первого дня, чтобы Redis, когда понадобится, был заменой одного класса, а не переписыванием.
Обратная связь: сигнал по WebSocket, данные по запросу
Осталась последняя стрелка: изменения должны лететь обратно. Собеседник выбрал провайдера в своём miniapp — у вас на странице должен обновиться статус; кто-то подключился к встрече — сообщение в чате должно это показать.
В части 1 я уже спойлерил: SignalR (WebSocket) внутри telegram-webview работает штатно на всех платформах. Схема такая:
При открытии страницы клиент вступает в группу по ключу общей сессии звонка: все участники одного звонка — в одной комнате.
Когда серверное состояние меняется, сервер шлёт в группу голое событие `StateChanged` — без данных.
Клиент, получив сигнал, сам запрашивает актуальное состояние обычным HTTP-запросом со своим персональным токеном.
```csharp
// сервер: состояние изменилось → пнуть группу (с debounce, см. ниже)
await hub.Clients.Group(callSessionKey).SendAsync("StateChanged");
// клиент: сигнал — не данные, а приглашение спросить
connection.on('StateChanged', () => refreshState()); // GET со своим токеном
```
Почему сигнал пустой? Три причины: не надо думать о правах в push-канале (каждый забирает состояние своим токеном — сервер сам решит, что ему видно); потерянный сигнал ничего не ломает (следующий `refreshState` всё выровняет); и события можно дебаунсить — при шквале изменений группа получает один пинок в N миллисекунд, а не очередь устаревших снапшотов. Плюс дешёвая страховка: редкий фоновый poll на случай, если WebSocket всё-таки умер.
Бонус-лайфхак: редактирование сообщений через очередь — иначе бан
Обратная связь долетает не только до miniapp, но и до того самого инлайн-сообщения в чате: «Готово. Подключились: Аня, Дмитрий». И вот здесь вайб-кодеры массово наступают на грабли: наивный код дёргает `editMessageText` на каждое изменение состояния. Два участника нажали кнопки одновременно — два edit'а; шквал событий — шквал edit'ов. А у Bot API на это две реакции: ошибка `400: message is not modified` (текст совпал с текущим) и flood-лимиты вплоть до временной блокировки бота — для продукта, который живёт в чужих чатах, это смерть.
Решение — не редактировать сообщение из бизнес-логики вообще. Вместо этого:
```text
логика: «состояние сессии X изменилось» → пометка X в очереди (дедупликация по ключу)
воркер: берёт ключ → строит текст и клавиатуру ИЗ ТЕКУЩЕГО состояния сессии
→ сравнивает с последним отправленным текстом (он хранится в сессии!)
→ совпало: молча пропустить | изменилось: editMessageText, запомнить текст
```
Три свойства, ради которых всё затевалось: дедупликация — десять изменений за секунду дают одно редактирование, потому что пометки схлопываются по ключу сессии, а текст строится по финальному состоянию; идемпотентность — сравнение с `LastInlineMessageText` из сессии гарантирует, что мы никогда не пошлём Telegram то, что у него уже есть (заметьте: это ещё одна работа для серверного состояния сессии); асинхронность — бизнес-логика не ждёт Telegram API и не падает от его ошибок.
Правило в память агента: сообщение в чате — это проекция состояния сессии, обновляемая фоновым воркером. Бизнес-логика сообщений не трогает.
Итого
Механика из этой статьи — переиспользуемый каркас для любого бизнес-приложения на miniapp, где есть «общая кнопка» и «выход наружу»: серверная сессия с типизированным состоянием; персональные токены поверх общего контекста; подпись initData как замена всей системе логина; пустые сигналы по WebSocket вместо данных в push; и очередь-проекция для сообщений в чате. Ни один из этих элементов не завязан на C# — это протокол работы с платформой.
В части 3 — фокусы: как бот «звонит» пользователю так, что телефон ведёт себя как при настоящем входящем вызове (спойлер: удаляем и переотправляем сообщение — и почему это работает). Почему в Telegram невозможен привычный веб-паттерн «клик → сервер сформировал ссылку → редирект» и как жить с тем, что конечный URL должен лежать в кнопке до клика. И скрипт-чат: онбординг-воронка целиком в одном JSON-файле — с эффектом печати, слайдами и аналитикой по шагам.
Всё описанное написано для Telegram, но в большей части справедливо и для MAX — механика ботов, miniapp и сессий там строится по тем же принципам. Если есть желание сделать адаптацию под MAX и российские сервисы видеовстреч — велком в личку.
Потрогать сам мост: @GoosleeBot · gooslibot.com
Показать полностью
Собеседовал программиста. Двадцать минут разговаривал с нейросетью
Собеседую сегодня программиста. Лет двадцать пять. Удалёнка, оба с вебками, всё по классике.
Первые минут десять - норм парень. Отвечает по делу, терминами сыпет, я на плюс вайбе.
А потом начинает царапать.
Отвечает правильно, но как-то… деревянно. Не разговаривает - зачитывает. Глаза в сторону. Постоянно косит на второй моник, будто там жена стоит с ремнём.
Ну ладно, думаю. Давай поиграем.
И начинаю разгоняться. Вопрос - вопрос - вопрос, без пауз, не даю выдохнуть. Парень задёргался, но тоже прибавил, держится.
И тут выдаёт:
«Понял ваш вопрос. Сейчас сформулирую вам ответ.»
Не «щас отвечу». СФОРМУЛИРУЮ ВАМ ОТВЕТ. Он даже не сказал своими словами. Читал прям как есть.
Я сижу, моргаю. Двадцать минут собеседую иишку.
Дальше уже всё сложилось. По технике - идеально, красавчик. Но в пустоту. Ни слова про наш проект, вообще ноль привязки к тому, чем мы занимаемся. Спрашиваю про опыт в похожих сферах - «да». Прошу конкретику - мяукает.
Ну естественно. Нейронка знает питон. Нейронка не знает, где этот челибос работал.
В конце уже чисто порофлу спрашиваю: слушай, а зачем тебе ИИ?
Включил дурачка. «Не понимаю, о чём вы». До последнего играл, стойкий гпт энджоер.
Не поженились, очевидно.
Но самый пиздец не в этом.
Он просил 350 тысяч.
Триста. Пятьдесят. Тысяч. За то, чтобы сидеть и копипастить из иишки.
За попытку и амбиции - респект, я восхищаюсь яйцами. Но 350 за ctrl+c это вы охуели конечно.
P.S. Аккаунт тут был лет десять назад, посты писал. Восстановить не смог — ни той почты, ни пароля. Так что формально новичок, фактически с 2015-го.
Показать полностью
МЛЯ, что не заменял штатный IT-отдел ОООшки, будучи фрилансером?
Случайных воспоминаний пост.
Как-то на одном форуме делились (около-)ITшными историями, вот и пришел на ум случай, разросшийся (в силу наличия здесь формата «МЛЯ») в этот лонг.
По основной работе я инженерю, а компами увлекаюсь с детства, хобби у меня такое. Народ вокруг в курсе, поэтому иногда собираю-настраиваю железки/софт, да консультирую еще, бывает.
И вот, лет 5 назад, обратился ко мне старый знакомый, пусть будет А., изначально с какими-то мелкими вопросами, а после их решения – с проблемой: работники его фирмы жалуются на постоянные тормоза ПК при работе, глюки доступа к 1С, частую недоступность компов и принтеров в сети, отваливающийся инет. Ок – это надо смотреть руками. Поехал.
Типичный офис: полдюжины сотрудников, с десяток wintel-ПК (ну, может, пара AMDшек) в одноранговой звезде на полуживой лапше, принтеры, SIP, из софта – офис + гуглопочта/мессенджеры + 1С, да пара специализированных прог. Иногда бывает удаленка, поэтому – AnyDesk, TeamViewer, вот это вот все. Компы – примерно 10-летней на тот момент давности (типа i3 – i5 на H61, Z77), юзеры – стандартные «пользователи программ».
Есть партнер А. – пусть будет Б. – занимающийся, к основным обязанностям, эникейщечеством: поставить винду, настроить роутер по инструкции, подключить принтер, завести 1С, решить (в рамках своих умений) какие-то юзерские траблы. А. представляет мне Б., говорит – работай по всем вопросам с ним, мы равны.
Инвентаризируем задачи: компы долго грузятся при включении, тормозят при работе, запуск 1С-ки превращает их в ждунов с непредсказуемым результатом, бывают вылеты прог и BSODы, принтеры артачатся сетевой печати.
Декомпозируем: рабочий юнит сотрудника – старенький ПК с HDD и 4-8 Гб памяти под Вин7, обслуживание харда/софта проводилось, видимо, никогда; доступ к файловым базам 1С, расположенным на «сервере» (т. по роли, по ОС/начинке он - обычный юнит), идет с клиентских компов по сети-сотке на неменеджируемом D-Link, IP и инет раздает роутер, включенный туда же.
По заданию Б., требуется:
1) заменить сеть на гигабит;
2) решить проблемы с серваком: утилизация сети и диска при использовании 1С – 100%;
3) излечить юниты от тормозов.
Плюсом идет экзотическое требование – чтобы «если придут» (цитата), можно было выключить сервер, при этом базы 1С должны стать недоступными.
И все это нужно сделать:
а) не останавливая постоянно работающий 5/2 офис (производство/продажи);
б) учитывая обычную «непростую финансовую ситуацию», а проще говоря – не за космический бюджет.
Решаем:
1) перетяжка сети (вообще первый раз это делал) на шилдованную Cat7 (благо, встройка юнитов гигабит держит) с заменой маршрутизатора;
2) замена потрохов сервака, установка баз 1С на SSD;
3) постепенная замена HDD на SSD в юнитах + добивка памятью + чистка/перемазка CPU/установка фанов + обслуживание софта.
По экзоту – будет криптоконтейнер на NTFS с монтированием в отдельный диск и последующим расшариванием его по сети.
Договариваемся: по первости попробовали формат разовых выездов, но, т.к. выяснилось, что никто IT-частью фирмы на постоянку не занимается, задач много, а Б. на все не хватает времени и квалификации, предложил – быть у них приходящим 2-3 раза в месяц админом, который решает текущие и возникающие вопросы, неподдающиеся Б., а также консультирует их всех по телефону в рабочее время. Это д.б. удобно и им (3 уровня поддержки: Б. на простые задачи, я по мобиле – на средние, я же, но руками – на сложные) и мне (наличие тайм-менеджмента + возможность удаленки). Сторговались на 20 тыр./мес со 100% авансированием.
Да, я сразу сказал А. и Б. и впоследствии неоднократно повторял (потом поймете – почему это важно) – с 1С незнаком, никогда не работал, суть и организацию ее не знаю, по ней помочь не смогу ничем. Но, т.к. у фирмы была контора на аутсорсе, что продавала им клиента 1С с поддержкой, с этим проблем не предвиделось.
В таком режиме и начали работу – я протянул новую четь, находил комплектуху и составлял запрос на выставление счета, после оплаты и доставки постепенно менял одно на другое + по приезду, решал мелкие текущие проблемы юзеров, проверял температурный режим компов, чистил темп/кэш браузеров/реестр и постепенно переводил парк ПК на современную основу. Ну и на звонки отвечал.
Параллельно (будучи, все же, инженером) анализировал возможные точки отказа – интернет, сеть, сервер, базы 1С – без доступа к чему работа этой фирмы невозможна. Рекомендовал решения – дублирование имеющегося инет-канала 4G-роутером, покупка вторых маршрутизатора и сервера для hot swap. Что-то делалось (дубль-4G), что-то – нет («работают и работают, да что с ними станется» – про резервные марш и сервак).
Понимая, что потеря баз 1С – катастрофична (как по рабочим, так и по чисто налогово-учетным причинам), а бюджет не планируется, нашел 2 старых 500Гб 2.5” HDD, кинул их во внешние боксы USB-SATA и сделал (в режиме пет-проекта) батник по резервному копированию файла криптоконтейнера на внешник с логгированием, поместив его в раз-в-недельный шедулер, и сказал менять винты по мере заполнения.
Прошло, наверное, года 4-5, мы пережили поднятие сервера после BSOD по телефону, частичный/полный апгрейд большинства техники в режиме «вечером взял, сделал - утром отдал», потерю роутера (оказалось, он был спрятан на другом этаже за запертой дверью), неожиданное (!) окончание срока действия сертификата Lets Encrypt с отвалом части сайтов и «фирменной» паникой (хоть винда и обновлялась, прописывать новый серт все равно пришлось ручками), переезд баз 1С с SSD на NVMe на PCI-ex райзере, увольнение Б. в связи с переездом (побоялся принудительно стать СВОлочью). Также собирал по просьбе А. и Б. им домашние компы, возился с привезенными на работу ноутами сотрудников фирмы. В общем – обычная текучка обычного IT-шника… НО – о чем бы тогда был этот пост?)
В один (не)счастливый день звонок от А. – доступа к базам 1С нет. Быстрая проверка показала: отвалился шаренный диск. Далее хуже – файл криптоконтейнера отсутствует, вместо него на диске нечто с рандомным названием и другим размером. Копирование и переименование результата не дает – контейнер не распознается. Диск с резервными копиями – битый. Ахтунг!
Говорю А. – отсоедини внешник и спрячь в сейф, это твоя единственная надежда. Понят не был – «какой смысл, в сейфе хранятся только дохлая мышь и бутылка». Отступаю – ничего не трогай, только выключи сервак, вечером приеду.
По приезду картина не лучше – на винте сервера явно багованный файл, внешник не читается. Поискали хоть какие-нибудь базы бухгалтерии – что-то есть, но не подключается и старье. А. позвонил в контору-саппорт, где 1 линия ничем помочь не смогла, а срок тикета на вторую – неделя-две( Сказали только – а что ж вы ЕЖЕДНЕВНО (!) не использовали штатные средства 1С по резервированию баз?
Повторно предлагаю – убери внешник в сейф и ищи профи, занимающихся восстановлением инфы. И тут… не знаю, упоминание сейфа ли триггером сработало, или нет, но на меня посыпались «джебы» – да как ТЫ мог не предусмотреть бэкап, почему диск с резервной копией был подключен к ТОМУ ЖЕ компу, на котором и основная база, зачем вообще этот криптоконтейнер и т.п. Я – в «сайдстеп»: с 1С не работал, как ее бэкапить не знаю (о чем предупреждал – вот оно!), задачу на крипту ставил Б. (с которым я работал, как с тобой), схему хоть какого-нибудь резервирования я вообще реализовывал сам на коленке. В ответ – «кросс»: почему не проявлял инициативу, не требовал (!) реализации полноценного бэкапа; и «хук»: вот у меня водитель, пока каждую мельчайшую детальку, должную быть в машине у меня не выбьет, никуда не поедет, а еще и инициативно ЗАРАНЕЕ требует закупить какие-то комплектующие. Я в легком «грогги», но клинчуюсь: во-первых, водила у тебя на почасовке и в штате, соответственно любой простой – это его деньги, поэтому инициатива понятна, а во-вторых – «апперкот»: ты всерьез думаешь, что за вшивую 30ку (да, оплата немного росла) при уволившемся Б. я заменю тебе весь штатный IT-отдел с фулл-погружением и инициативами?
Ладно, там еще наложилось увольнение проштрафившегося буха с одновременным поиском нового, соответственно - необходимостью вот срочной работы с базами, да и отчет в налоговую маячил на горизонте. Нервенно, в общем. Взяли брейк.
На следующий день звонок А. – нашелся спец по рекавери, еду к нему с внешником. Созвон со спецом – он что-то восстановил, как проверить? Даю пароль (да, к тому времени уже и я его знал), и, О ЧУДО! - открывается контейнер. Правда, 2-месячной давности, но это уже мелочи. Вечером опять еду, предварительно заказав и получив 5 (!) флешек (по требованию А) для бэкапа, процедуру которого контора 1С-саппорта сообщила-таки А. Подключил, скопировал, расшарил – заработало. Решили выкинуть крипту – ок, сделал. Вроде, все гут…
Но нет, опять претензии А.: я на тебя рассчитывал, ты не оправдал доверия, ты не то, ты не это. Начинаю: да я ж единственный человек, благодаря которому у тебя была хотя бы призрачная возможность все не потерять, только мой пет-проект дал второй диск с доступным для восстановления контейнером… Вообще - это твой бизнес и ты должен думать о ВСЕХ последствиях и если делегируешь – то с четко обговоренными условиями и адекватной оплатой. Полный игнор. Бой с тенью какой-то… Ок, разъехались.
Еще пару раз А. звонил, какие-то мелкие вопросы по работе ПК решали. Кончился месяц, пишу – дальше будем работать? В ответ тишина… Ну, что ж - было интересно посотрудничать.
И вот после всего этого созрел вопрос – красавчег ли я, предусмотрев возможную проблему и решив ее, хоть и не без потерь, или иллюстрацией вики-статьи «Гнида» должно быть мое фото?
Показать полностью